Electronics to remotely monitor and control a machine via a mobile personal communication device

ABSTRACT

Embodiments may monitor operation of a machine and provide feedback to maintain use within certain parameters. Mobile personal communication device sensors are each configured to monitor at least one machine parameter (speed, acceleration, location, etc.), generate a signal encapsulating the monitored machine parameter, and transmit the generated sensor signals to a control unit of the communication device. The control unit may receive the generated sensor signals, store the received signals, and selectively combine the received signals. The communication device also includes a transmitter coupled to the control unit capable of transmitting the combined signal. A transceiver remote from the machine may determine a current machine condition and compare that condition to received conditions from other machines. Feedback may then be provided to adjust operation of the machine based on the comparison. For example, an operator interface may provide audio and/or visual feedback to the operator of a vehicle.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/110,026 entitled “ELECTRONICS TO REMOTELY MONITOR ANDCONTROL A MACHINE VIA A MOBILE PERSONAL COMMUNICATION DEVICE” filed onAug. 23, 2018. The entire contents of this application is incorporatedherein by reference.

BACKGROUND

Machines, such as motor vehicles and the like, are often used in anon-complaint manner. That is, machines are used beyond the rules andlaws that define their use. Often operators of machines misrepresent orunderrepresent how they use their machines. Sometimes suchmisrepresentations are intentional to enable the user to obtain certainbenefits and to be able to use the machines outside the rules and laws.Other times, operators do not even realize how they operate the machine.As such, a need exists for electronics for remotely monitoring and/orcontrolling the use of a machine. Moreover, it may be desirable toprovide systems and methods for remotely monitoring and/or controllingthe use of a machine that provides faster, more accurate results.

SUMMARY OF THE INVENTION

According to some embodiments, systems, methods, apparatus, computerprogram code and means are provided for remotely monitoring and/orcontrolling the use of a machine that provides faster, more accurateresults and that allow for flexibility and effectiveness when respondingto those results. Some embodiments may monitor operation of a machineand provide feedback to maintain use within certain parameters. Mobilepersonal communication device sensors are each configured to monitor atleast one machine parameter (speed, acceleration, location, etc.),generate a signal encapsulating the monitored machine parameter, andtransmit the generated sensor signals to a control unit of thecommunication device. The control unit may receive the generated sensorsignals, store the received signals, and selectively combine thereceived signals. The communication device also includes a transmittercoupled to the control unit capable of transmitting the combined signal.A transceiver remote from the machine may determine a current machinecondition and compare that condition to received conditions from othermachines. Feedback may then be provided to adjust operation of themachine based on the comparison. For example, an operator interface maybroadcast audio and/or visual feedback to the operator of a vehicle.

Some embodiments comprise: means for accessing a risk relationship datastore containing electronic records, each electronic record including arisk relationship identifier along with at least one operator identifierand at least one machine identifier; means for receiving, at a back-endapplication computer server, machine information representing operationof the machine, from an application executing on the mobile personalcommunication device, including at least one of geo-position informationand machine kinematics data, via a distributed communication network;means for determining a risk relationship identifier associated with thereceived machine information; based on the received machine information,means for automatically predicting an operator identifier associatedwith the received machine information, wherein said prediction utilizesa prediction algorithm based on a pattern detected via a machinelearning analysis of past operator usage of the machine; means forcalculating a risk score for the risk relationship based on the at leastone of the geo-position information and machine kinematics data alongwith the predicted operator identifier; and means for updating theappropriate electronic record in the risk relationship data store withthe calculated risk score.

In some embodiments, a communication device associated with a back-endapplication computer server exchanges information with remote devices inconnection with an interactive graphical user interface. The informationmay be exchanged, for example, via public and/or proprietarycommunication networks.

A technical effect of some embodiments of the invention is an improvedand computerized way for remotely monitoring and/or controlling the useof a machine that provides faster, more accurate results. With these andother advantages and features that will become hereinafter apparent, amore complete understanding of the nature of the invention can beobtained by referring to the following detailed description and to thedrawings appended hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example system architecture that may be used forremotely monitoring the use of a vehicle.

FIG. 2A shows a flow diagram for a method for determining pricing basedon driver signatures associated with a vehicle.

FIG. 2B shows a flow diagram for a method for expectation basedprocessing.

FIG. 2C shows a flow diagram for a method for destination basedunderwriting.

FIG. 2D shows a flow diagram for a method for telematics basedunderwriting.

FIG. 3 is an example web page for initiating a request for a vehicleinsurance quote.

FIG. 4 is a high-level block diagram of a system in accordance with someembodiments.

FIG. 5 illustrates a method according to some embodiments of the presentinvention.

FIG. 6 illustrates a method to account for the various autonomousvehicle systems that may be included within a vehicle in pricing aninsurance policy.

FIG. 7 shows an example configuration for determining a driver signaturebased on telematics data.

FIG. 8 shows an example configuration for determining a driver signaturebased on telematics data that accounts for a seasonality factor.

FIG. 9 shows three examples of assessing a driver's risk based ontelematics data collected on actual driving behavior relative to theexpected driving behavior.

FIG. 10 shows an example of a location risk map used in accordance withone embodiment.

FIG. 11 shows an example diagram of an embodiment of a system fortelematics based underwriting.

FIG. 12 shows a flow diagram for a method for determining pricing basedon driver signatures associated with a vehicle.

FIG. 13 shows another flow diagram for a method for expectation basedprocessing.

FIG. 14 shows a flow diagram for a method for destination basedunderwriting.

FIG. 15 shows an example graph for a driving location risk index for alocation based calculation, wherein the location size is based on thezip code.

FIG. 16 is an architectural model of a system for determining a discountfor an insurance premium based on telematics data, according to anillustrative embodiment of the invention.

FIG. 17 illustrates an automobile in accordance with some embodiment ofthe invention.

FIG. 18 is a flowchart of a method according to an illustrativeembodiment of the invention.

FIGS. 19 and 20 illustrate map displays in accordance with someembodiments described herein.

FIGS. 21 and 22 illustrate current telematics displays according to someembodiments.

FIG. 23 illustrates a safety score display according to someembodiments.

FIG. 24 illustrates a likely discount display according to someembodiments.

FIG. 25 illustrates how an insurance premium might change over timeaccording to some embodiments.

FIGS. 26 and 27 are examples of insurance discount calculator displaysin accordance with some embodiments described herein.

FIG. 28 is a block diagram of an apparatus in accordance with someembodiments of the present invention.

FIG. 29 is a portion of a smartphone data database according to someembodiments.

FIG. 30 is a portion of a tabular vehicle database in accordance withsome embodiments.

FIG. 31 is a portion of a tabular driver database according to someembodiments.

FIG. 32 is a real-time information flow diagram of a processing systemin accordance with some embodiments.

DETAILED DESCRIPTION

The present invention provides significant technical improvements tofacilitate electronic messaging and dynamic data processing. The presentinvention is directed to more than merely a computer implementation of aroutine or conventional activity previously known in the industry as itsignificantly advances the technical efficiency, access and/or accuracyof communications between devices by implementing a specific new methodand system as defined herein. The present invention is a specificadvancement in the area of machine monitoring, control, and/or analysisby providing benefits in data accuracy, data availability and dataintegrity and such advances are not merely a longstanding commercialpractice. The present invention provides improvement beyond a meregeneric computer implementation as it involves the processing andconversion of significant amounts of data in a new beneficial manner aswell as the interaction of a variety of specialized client and/orthird-party systems, networks, and subsystems. For example, in thepresent invention information may be processed, updated, and analyzedvia a back-end-end application server to accurately improve machinelearning algorithms and the exchange of information, thus improving theoverall efficiency of the system associated with message storagerequirements and/or bandwidth considerations (e.g., by reducing thenumber of messages that need to be transmitted via a network). Moreover,embodiments associated with collecting accurate information mightfurther improve risk values, predictions of risk values, allocations ofresources, risk relationship decisions, etc.

A system and method configured to monitor use conditions of a vehicleand provide feedback to a user of the vehicle to maintain use withincertain parameters is described. The description includes a plurality ofsensors located proximate to the vehicle, each sensor configured tomonitor at least one vehicle parameter, the plurality of sensorsselected from an accelerometer, speed, temperature, mileage, oil level,oil pressure, run-time and location sensors, each sensor generating asignal encapsulating the monitored vehicle parameter and transmittingthe generated signal to a control unit. The description includes acontrol unit that receives the generated signal from each of a pluralityof sensors, the control unit including a memory that stores the receivedsignal and selectively combines the received signal with other signalsreceived from others of the plurality of sensors. The descriptionincludes a first transmitter coupled to the control unit capable oftransmitting the combined signal. The description includes a secondtransceiver remote from the vehicle that receives a transmittedcondition, and compares that condition to received conditions from othervehicles and provides feedback to adjust the use of the vehicle based onthe comparison, and a user interface for providing feedback to a userincluding at least one of visual indication, audible indication, andphysically altering the use of the vehicle. The description includescoupling of the plurality of sensors to the control unit with acontroller area bus (CAN). The first transmitter may transmit over an RFnetwork.

FIG. 1 shows an example system 100 that may be used for monitoring avehicle. The example system 100 includes a vehicle 140 having anoperator with a smartphone 110 executing a telematics application suchas a TrueLane® application. The telematics devices may further includetablets, laptops, OEM connectivity devices and/or similar devices. Thevehicle 140 may be in communication with multiple devices over differentnetworks, including a satellite, a cellular station, a Wi-Fi hotspot,BLUETOOTH devices, and/or a smartphone 110 (which might insteadcommunicate directly with cellular stations and/or Wi-Fi hotspots andnot the vehicle 140). The smartphone 110 may be operated by athird-party vendor that collects telematics data. The smartphone 110 mayinclude storage. The smartphone 110 may sense and collect the telematicsdata and then transmit the telematics data to a Data Processing Unit(“DPU”) 170. The telematics data may be communicated to the DPU 170 inany number of formats. The telematics data may be transmitted as rawdata, it may be transmitted as summary data, or it may be transmitted ina format requested by the DPU 170. For example, the DPU 170 may transmita customized summary of the telematics data to the DPU 170, in a formatusable by the DPU 170. The DPU 170 may also be configured to communicatewith a Risk and Pricing Unit (“RPU”) 160 including storage 162, internalservers 180, including storage 182, and external servers 190 (e.g.social media networks, official/government networks), which are allconnected by one or more networks.

The one or more telematics devices associated with the vehicle 140 maycommunicate with a satellite, Wi-Fi hotspot, BLUETOOTH devices and evenother vehicles. The telematics devices associated with the vehicle 140report this information to the smartphone 110 which may also directlydetect telematics data. As will be described in greater detailhereafter, the smartphone 110 may transmit this telematics data to theDPU 170 which may be configured to consolidate biographic and telematicsdata to monitor the use of the vehicle 140.

The web site system 120 provides a web site that may be accessed by auser device 130. The web site system 120 includes a Hypertext TransferProtocol (“HTTP”) server module 124 and a database 122. The HTTP servermodule 124 may implement the HTTP protocol, and may communicateHypertext Markup Language (“HTML”) pages and related data from the website to/from the user device 130 using HTTP. The web site system 120 maybe connected to one or more private or public networks (such as theInternet), via which the web site system 120 communicates with devicessuch as the user device 130. The web site system 120 may generate one ormore web pages that provide communication setting information, maycommunicate the web pages to the user device 130, and may receiveresponsive information from the user device 130.

The HTTP server module 124 in the web site system 120 may be, forexample, an APACHE HTTP server, a SUN-ONE Web Server, a MICROSOFTInternet Information Services (“ITS”) server, and/or may be based on anyother appropriate HTTP server technology. The web site system 120 mayalso include one or more additional components or modules (notdepicted), such as one or more load balancers, firewall devices,routers, switches, and devices that handle power backup and dataredundancy.

The user device 130 may be, for example, a cellular phone (including thesmartphone 110), a desktop computer, a laptop computer, a tabletcomputer, or any other appropriate computing device. The user device 130may further be configured to operate as a telematics device. The userdevice 130 includes a web browser module 132, which may communicate datarelated to the web site to/from the HTTP server module 124 in the website system 120. The web browser module 132 may include and/orcommunicate with one or more sub-modules that perform functionality suchas rendering HTML (including but not limited to HTML5), rendering rasterand/or vector graphics, executing JavaScript, and/or renderingmultimedia content. Alternatively or additionally, the web browsermodule 132 may implement Rich Internet Application (“RIA”) and/ormultimedia technologies such as ADOBE FLASH, MICROSOFT SILVERLIGHT,and/or other technologies. The web browser module 132 may implement RIAand/or multimedia technologies using one or more web browser plug-inmodules (such as, for example, an ADOBE FLASH or MICROSOFT SILVERLIGHTplug-in), and/or using one or more sub-modules within the web browsermodule 132 itself. The web browser module 132 may display data on one ormore display devices (not depicted) that are included in or connected tothe user device 130, such as a liquid crystal display (LCD) display ormonitor. The user device 130 may receive input from the user of the userdevice 130 from input devices (not depicted) that are included in orconnected to the user device 130, such as a keyboard, a mouse, or atouch screen, and provide data that indicates the input to the webbrowser module 132.

The example system 100 of FIG. 1 may also include one or more wiredand/or wireless networks (not depicted), via which communicationsbetween the elements in the example system 100 may take place. Thenetworks may be private or public networks, and/or may include theInternet.

Each or any combination of the modules shown in FIG. 1 may beimplemented as one or more software modules, one or morespecific-purpose processor elements, or as combinations thereof.Suitable software modules include, by way of example, an executableprogram, a function, a method call, a procedure, a routine orsub-routine, one or more processor-executable instructions, an object,or a data structure. In addition or as an alternative to the features ofthese modules described above with reference to FIG. 1 , these modulesmay perform any of the functionality described herein.

The smartphone 110 may include one or more sensors, such as anaccelerometer, speed and location sensors, for example. By way ofnon-limiting example only, these sensors may include temperature as wellas systems that provide other types of vehicle data. Other types ofsensors including impact sensors, chemical sensors and pressure sensorsmay be utilized in the present system.

FIG. 2A shows an example for a method 205 for determining driversignatures. The system 100 receives biographical information regardingthe user (S206). This information may include information (such as thenumber of family members, age, marital status, education, addressinformation, number and type of vehicles). Based on this information,the system 100 may create a group account (S207). The group account mayinclude subaccounts for each vehicle, wherein each vehicle may havemultiple drivers. For each vehicle, the system 100 may create a useprofile. The use profile is based on the indicated amount of use of eachvehicle, by each driver. The system 100 may use correlative data basedon stored information (including historic driver data associated witheach driver, statistical/demographic information, and biographical data)and other actuarial factors to determine a risk assessment associatedwith insuring each vehicle. This risk assessment may include expectedclaims and/or losses associated with the vehicle. The system 100 may usethis risk assessment to determine pricing information for the account.This initial risk assessment may be based on correlative data (i.e.using the biographic/demographic data as a proxy for actual drivingbehavior.) This may include driver risk assessment, vehicle riskassessment, policy risk assessment or any appropriate risk assessment.The risk assessment may be represented as a profile, a score (or set ofscores) or similar information stored in a database. Once the system 100has generated the group account, it may begin to receive and store thevehicles' telematics data received from a “mobile personal communicationdevice,” such as a smartphone or smartwatch (S208). As used herein, thephrase “mobile personal communication device” may refer to any divehaving a primary purpose other than detecting and/or collectingtelematics data. In this, and insurance enterprise may leverage hardwarealready owned by consumers to appropriately administer insurancepolicies. The system 100 may use software based algorithms to analyzereceived telematics data. For example, the system 100 may be configuredto cluster certain driver characteristics in the telematics data toidentify discrete segments of use associated with a particular driversignature. The system 100 may be configured to associate each of thesedriver signatures with a driver (known or unknown) (S209). The system100 may then categorize the usage of each vehicle based on these driversignatures. In one example, the system 100 may determine the amount oftime each vehicle is used by driver signatures associated with known andunknown drivers. The system 100 may adjust the risk assessmentassociated with the vehicle based on the number of driver signaturesidentified as well as an analysis of the type of driving the driversignature indicates (e.g. aggressive, distracted, cautious, etc.)(S210). The risk assessment, generated by the system 100, may be a riskprofile associated with the vehicle or the driver.

Once the driver signature is determined, the telematics data may bestored as data using attributes of the driver. This database storage ofthe captured telematics signals may reduce the data and identify thedriver based on the attributes of the driver signature. The databasestoring by identified driver, as an attribute of the driver, improvesthe efficiency and power usage of the processor in accessing and usingthe signals from the telematics data.

Alternatively, the system 100 may be configured to generate an aggregaterisk profile for the group of vehicles, without individually assessingeach driver or vehicle. Based on these driver signatures, the system 100may be configured to assess the risks associated with coverage based oncausal data in addition to or instead of correlative data. The system100 may use these risks to adjust the pricing information (S211). Thepricing information may be adjusted by adjusting the assessed rate, orproviding the customer with a discount, a credit or a penalty. Inanother example, the pricing information may be adjusted by placing thevehicle or driver in a different rate category.

FIG. 2B shows an example for a method 215 for expectation basedprocessing. The system 100 receives registration information regardingthe user (S216). This information may include biographical information(such as the numbers of family members, age, marital status, education,address information, number and type of vehicles). Based on thisinformation, the system 100 creates a group account (S217). The groupaccount may include subaccounts for each individual driver (in the caseof multiple insured). The system 100 uses a software based algorithm togenerate initial driver risk profiles, based on stored loss statistics.The system 100 may then generate pricing information based on thisinitial risk profile (S218). If the user accepts the pricing, theaccount is activated and the system 100 begins receiving and storesdriver telematics data (associated with the account) that is receivedfrom a smartphone (S219). At predetermined or requested intervals, thesystem compares the received telematics data and compares each measuredvalue with the expected value in the initial driver risk profile (S220).Using software based algorithms, the system 100 may credit or penalizeeach driver based on variances from the initial driver expectationprofile and determine pricing information, including adjusting a rate,providing a credit or penalty, deny coverage, or recommend a differentinsurance product (S221). As opposed to previous systems which merelyadjusted rates on a whole premium basis. The system 100 is configured toadjust the pricing based on multiple factors determined by thetelematics data. The system 100 may be able to adjust the pricing inmultiple ways, for example by adjusting the rate, or providing a credit,or a penalty, based on the telematics data. Alternatively, the system100 may be configured to generate an initial risk profile on a groupbasis. For example, for a family of four with two cars and four drivers,an aggregate initial risk profile may be generated. Based on thisaggregate initial risk profile, the group is assessed a premium based ondriver averaging. Accordingly, if the aggregate telematics data variesfrom the aggregate initial driver risk profile, the pricing may beadjusted by adjusting the rate, crediting or penalizing the account,denying continuing coverage, or recommending a different insuranceproduct for the user. The updated pricing information may be presentedto the user of a user device 130. The techniques described herein may beused to compare various methods of determining the pricing of vehicleinsurance. For example, some companies may use a blended rate todetermine premiums; others may determine this based on attributing theworst driver on a policy to the highest risk vehicle. Using the methodsdescribed herein, the insurance company can adjust the pricinginformation from either scheme.

FIG. 2C shows an example for a method 225 for destination basedunderwriting. The system 100 receives registration information regardingthe user (S226). This information may include biographical information(such as the numbers of family members, age, marital status, education,address information, number and type of vehicles). In one embodiment,this information may be received via a website. Based on thisinformation, the system 100 creates a group account (S227). The groupaccount may include subaccounts for each individual driver (in the caseof multiple insured). The system 100 uses a software based algorithm togenerate initial risk assessments, based on stored statistical data andloss data. For example, if there are two drivers and two vehicles, andeach vehicle is driven by only one driver, the system 100 generates avehicle risk assessment which incorporates the likelihood of a claimbeing made related to the vehicle 140 and the expected severity of sucha claim. The initial risk assessment may be based on the expectedlocations in which the vehicle 140 is to be stored and the expected riskbehavior of the operator of the vehicle 140. The system 100 may thengenerate pricing information based on this initial risk assessment(S228). For example, the pricing information may include a quote or apremium for the user. If the user accepts the premium, the account isactivated and the system 100 begins receiving and storing telematicsdata (associated with the account) from a personal mobile communicationdevice (S229). At predetermined intervals or based on triggering events,the telematics device may push telematics data to the system 100, or thesystem 100 may pull telematics data from the device and store theinformation in a database. The system 100 receives the telematics data,and categorizes information as destination information (S230). Forexample, the system 100 may receive location updates every 10 seconds.If the vehicle 140 is stopped, for more than a predetermined time period(e.g. 15 minutes) it may register a location as a destination location.The system 100 may further be configured to access external real-timedata, such as traffic data to refine its information. For example, if avehicle 140 is stopped for more than 15 minutes, and the location isdetermined to be a high traffic location, the system 100 may determinethat the stoppage is not a destination, but a traffic related stoppage.The system 100 may then use the determined destination information andperform a software based statistical analysis and determine a directexposure risk rating and an indirect exposure risk rating for eachstoppage. The direct exposure risk rating and an indirect exposure riskrating are inputs to a unified Telematics Destination Score (TDS) thatis calculated at some unit of location such as a zip code or a censusblock (S231). The TDS, which may be comprised of a direct exposure riskrating and indirect exposure risk rating, may be compared with theinitial risk assessment (S232). Using software based algorithms, thesystem 100 may credit or penalize each vehicle 140 based on variancesfrom the initial risk assessment and adjust the pricing information,wherein the adjusted pricing information may comprise a premium based onadjusted rates, credits, debits, or changes in a class plan.Additionally, the system 100 may deny coverage, or recommend a differentinsurance product (S233).

FIG. 2D shows an example for a method 235 for telematics basedunderwriting. The system 100 receives registration information regardingthe user (S236). This information may include biographical information(such as the numbers of family members, age, marital status, education,address information, number and type of vehicles). In one embodiment,this information may be received via a website. Based on thisinformation, the system 100 creates a group account (S237). The groupaccount may include subaccounts for each individual driver (in the caseof multiple insured). The system 100 uses a software based algorithm togenerate initial risk assessments, based on stored demographic data andloss data. For example, if there are two drivers and two vehicles, andeach vehicle is driven by only one driver, the system 100 generates avehicle risk assessment which incorporates the likelihood of a claimbeing made related to the vehicle and the expected severity of such aclaim. The initial risk assessment may be based on the expectedlocations in which the vehicle is to be stored and the expected riskbehavior of the operator of the vehicle. The system 100 may thengenerate pricing information based on this initial risk assessment(S238). For example, the pricing information may include quote/premiuminformation. If the user accepts the premium, the account is activatedand the system 100 begins receiving and stores telematics data(associated with the account) from a personal mobile communicationdevice (S239). At predetermined intervals or based on triggering events,the telematics device may push telematics data to the system 100 or thesystem 100 may pull telematics data from the device and store theinformation in a database. The system 100 receives the telematics data,and determines a plurality of relativity factors (S240). The system 100may then use the determined relativity factors to determine a discountrelativity (S241). The system 100 may compare the determined discountrelativity to a predetermined threshold to determine whether to providea discount (S242). Using software based algorithms, the system 100 maycredit or penalize each vehicle based on the comparison of the discountrelativity to the predetermined threshold and determine an adjustedrate, an adjusted risk score, provide a credit or surcharge, denycoverage, or recommend a different insurance product (S243).

FIG. 3 shows an example web page that may be displayed by the webbrowser module 132. The web pages may include display elements whichallow the user of the user device 130 (or smartphone 110) to interfacewith the system 100 and register or receive a quote for vehicleinsurance. The web pages may be included in a web browser window 200that is displayed and managed by the web browser module 132. The webpages may include data received by the web browser module 132 from theweb site system 120. The web pages may include vehicle insuranceinformation.

The web browser window 200 may include a control area 265 that includesa back button 260, forward button 262, address field 264, home button266, and refresh button 268. The control area 265 may also include oneor more additional control elements (not depicted). The user of the userdevice 130 may select the control elements 260, 262, 264, 266, 268 inthe control area 265. The selection may be performed, for example, bythe user clicking a mouse or providing input via keyboard, touch screen,and/or other type of input device. When one of the control elements 260,262, 264, 266, 268 is selected, the web browser module 132 may performan action that corresponds to the selected element. For example, whenthe refresh button 268 is selected, the web browser module 132 mayrefresh the page currently viewed in the web browser window 200.

FIG. 3 is an example web page 302 for initiating a request for a vehicleinsurance quote. As shown in FIG. 3 , the web page 302 may includequestions accompanied by multiple input fields 305, 306 in the form ofdrop down lists, text fields, and radio buttons. As the user providesinput into the input fields 305, 306, the web browser module 132 maystore one or more data structures (“response data”) that reflect theselections made in the input fields 305, 306. Further, as the selectionsare updated, the web browser module 132 may update the web page 302 toindicate additional or more specific questions that may be associatedwith the selections. If there are no errors in the transmission, the webbrowser module 132 is directed to a subsequent web page. While theexample shown is for auto insurance, the methods and apparatus disclosedherein may be applied to any vehicle insurance, e.g. boats, planes,motorcycles etc. Also, while the examples are directed to family autoinsurance, the methods and apparatus disclosed herein may be applicableto corporate insurance plans, or any policies covering vehicles. The webpage 302 may further include an option of registering a phone 307 withthe insurance program. For example, the phone registration 307 may senda telephone number to a central server, install a telematics applicationon a smartphone, etc.

FIG. 4 is a high-level block diagram of a system 400 according to someembodiments of the present invention. In particular, the system 400includes a back-end application computer 450 server that may accessinformation in a risk relationship data store 410 (e.g., storing a setof electronic records 412 representing risk associations, each recordincluding, for example, one or more risk relationship identifiers 414,attribute variables 416, insurance premiums 418, etc.). The back-endapplication computer server 450 may also retrieve information from otherdata stores or sources in connection with a driver prediction algorithm455 (e.g., trained via machine learning) to update the electronicrecords based on a likely driver of a vehicle. The back-end applicationcomputer server 450 may also exchange information with a remote machine460 or smartphone 465 associated with the machine 460 (e.g., via afirewall 467). According to some embodiments, an interactive graphicaluser interface platform of the back-end application computer server 450(and, in some cases, third-party data) may facilitate forecasts,decisions, predictions, and/or the display of results via one or moreremote administrator computers (e.g., to gather additional informationabout an existing association) and/or the remote user device 460. Notethat the back-end application computer server 450 and/or any of theother devices and methods described herein might be associated with athird-party, such as a vendor that performs a service for an enterprise.

The back-end application computer server 450 and/or the other elementsof the system 400 might be, for example, associated with a PersonalComputer (“PC”), laptop computer, smartphone, an enterprise server, aserver farm, and/or a database or similar storage devices. According tosome embodiments, an “automated” back-end application computer server450 (and/or other elements of the system 400) may facilitate updates ofelectronic records in the risk relationship data store 410. As usedherein, the term “automated” may refer to, for example, actions that canbe performed with little (or no) intervention by a human.

As used herein, devices, including those associated with the back-endapplication computer server 450 and any other device described hereinmay exchange information via any communication network which may be oneor more of a Local Area Network (“LAN”), a Metropolitan Area Network(“MAN”), a Wide Area Network (“WAN”), a proprietary network, a PublicSwitched Telephone Network (“PSTN”), a Wireless Application Protocol(“WAP”) network, a Bluetooth network, a wireless LAN network, and/or anInternet Protocol (“IP”) network such as the Internet, an intranet, oran extranet. Note that any devices described herein may communicate viaone or more such communication networks.

The back-end application computer server 450 may store information intoand/or retrieve information from the risk relationship data store 410.The risk relationship data store 410 might, for example, storeelectronic records representing a plurality of existing riskassociations, each electronic record having a set of attribute valuesincluding an insurance premium. The risk relationship data store 410 mayalso contain information about prior and current interactions withparties, including those associated with the remote user devices 460.The risk relationship data store 410 may be locally stored or resideremote from the back-end application computer server 450. As will bedescribed further below, the risk relationship data store 410 may beused by the back-end application computer server 450 in connection withsmartphone 465 to improve the operation or performance of the machine460. Although a single back-end application computer server 450 is shownin FIG. 4 , any number of such devices may be included. Moreover,various devices described herein might be combined according toembodiments of the present invention. For example, in some embodiments,the back-end application computer server 450 and a payroll server mightbe co-located and/or may comprise a single apparatus.

Note that the system 400 of FIG. 4 is provided only as an example, andembodiments may be associated with additional elements or components.According to some embodiments, the elements of the system 400automatically transmit information associated with an interactive userinterface display over a distributed communication network. FIG. 5illustrates a method 500 that might be performed by some or all of theelements of the system 400 described with respect to FIG. 4 , or anyother system, according to some embodiments of the present invention.The flow charts described herein do not imply a fixed order to thesteps, and embodiments of the present invention may be practiced in anyorder that is practicable. Note that any of the methods described hereinmay be performed by hardware, software, or any combination of theseapproaches. For example, a computer-readable storage medium may storethereon instructions that when executed by a machine result inperformance according to any of the embodiments described herein.

At S510, the system may access a risk relationship data store containingelectronic records, each electronic record including a risk relationshipidentifier along with at least one operator identifier and at least onemachine identifier. At S520, a back-end application computer server mayreceive machine information, representing operation of the machine, froman application executing on the mobile personal communication device(e.g., a smartphone). The received machine information might include,for example, at least one of geo-position information and machinekinematics data, via a distributed communication network. At S530, thesystem may determine a risk relationship identifier associated with thereceived machine information.

Based on the received machine information, the system may automaticallypredict at S540 an operator identifier associated with the receivedmachine information. According to some embodiments, the predictionutilizes a prediction algorithm based on a pattern detected via amachine learning analysis of past operator usage of the machine. Themachine learning analysis might be associated with, for example, alocation of operation, a time-of-day of operation, a day-of-week ofoperation, a time-of-year of operation, etc. According to someembodiments, the machine is a vehicle that exchanges information withthe mobile personal communication device. In this case, the driverprediction may be based at least in part on the exchanged information,such as a manual driver selection, a location of the mobile personalcommunication device within the vehicle, a command to start the vehicle,telematics information associated with the vehicle, etc.

At S550, the system may calculate a risk score for the risk relationshipbased on the at least one of the geo-position information and machinekinematics data along with the predicted operator identifier. At S560,the system may then update the appropriate electronic record in the riskrelationship data store with the calculated risk score. According tosome embodiments, the application executing on the mobile personalcommunication device is further to identify distracted operation of themachine and the calculated risk score is further based on distractedoperation. Examples of distracted operation may include accessing a textmessage, creating a text message, participating in a telephone call,accessing an email message, accessing streaming video, a chatapplication, etc.

According to some embodiments, the calculated risk score is furtherbased on at least one machine safety feature associated with the machineidentifier. For example, when the machine is a vehicle the safetyfeature might be associated with adaptive headlights, an autonomousoperation feature, a camera, a sensor, an automatic braking feature, abrake warning feature, a parking feature, a lane departure warning, etc.According to some embodiments, the machine identifier is a vehicleidentifier and a determination that a safety feature is associated withthe vehicle identifier is based on a safety feature database containingindications of safety features in connection with vehicle identifiers.The safety feature database might be maintained by, for example, avehicle manufacturer, vehicle dealerships, a governmental department ofmotor vehicles, a third-party service, etc.

According to some embodiments, the machine is a vehicle, the riskrelationship is an automobile insurance policy, the operator is adriver, the enterprise is an insurance company, and the mobile personalcommunication device is a smartphone. In such cases, the risk scoremight be used to adjust an insurance premium percentage discount, aninsurance premium monetary discount, an insurance coverage amount, adeductible amount, etc. Moreover, the automobile insurance policy mightbe associated with a potential automobile insurance policy, a newlyissued automobile insurance policy, an automobile insurance policyrenewal, etc.

In order to account for the various autonomous vehicle systems that maybe included within a vehicle in pricing an insurance policy for thevehicle, the method 600 illustrated in FIG. 6 may be used. In step S610,a determination may be made, as described herein, of a driver signature.

In step S620, the autonomous features or systems of the vehicle may beidentified. As described herein, this information may be collected viawebpages or otherwise collected, such as manually entered or receivedvia a third-party like an after-market installation company or atracking company such as CarFax®. Importantly, in step S620, adetermination is made regarding the features of the vehicle. That is, ifthe vehicle has autonomous features and if so which ones. If thefeatures are present, where the features installed as stock features oradded features installed by the dealer, or where the features addedafter market by an after-market retailer or the owner of the vehicle.

Method 600 may include a verification that the identified autonomousvehicle features are being used at S630. In step S630, a determinationis made regarding the use of the feature, i.e., was the feature on/offduring use of the vehicle. A feature may be configured to be always“on.” Alternatively, a feature's use value may be determined from thetelematics information as described herein. A proxy may be used forrepresenting how much a feature may be “on.” For example, if ananti-locking breaking is installed on the car, verification of the factthat the anti-lock braking system is operational (turned on) may be theinitiator of the reduced insurance premium. For example, if the systemis installed in the vehicle, but the driver (or other operator such asan owner) of the vehicle disables the system or otherwise turns thesystem off, the vehicle may not qualify for that respective discountwhile configured in this way. However, the fact that the autonomousfeatures are included on the vehicle may still provide some discount,because for example owners of vehicles with autonomous features may beknown to be safer, for example.

Method 600 may provide a rate based on the driver signature (asdiscussed herein) and the in-use (including discount for having avehicle with certain safety features even if the feature(s) are off)identified autonomous vehicle features at S640. This rate may be basedon which types of autonomous features are used, how frequently thefeatures are used, which driver the features displace, the combinationsof features being used, and the like.

By way of example, a certain combination of autonomous features that arein use, such as forward collision breaking and backup braking, may beknown to reduce accidents and may be combined to provide a larger ratereduction for the vehicle than potential other combinations ofautonomous features. Each autonomous feature may have its use weightedin the ultimate calculation of premiums. The weight provided for afeature may be based on the amount of safety that the feature providesrelative to the risk associated with the driving that is beingperformed. Some, or all, of the features may have the same weight whenperforming rate reduction calculations.

Further, autonomous features that take the place of drivers who areknown to be particularly prone to accidents provide a further ratereduction with respect to those features that are replacing relativelysafer drivers, for example. The statistics show that 92% of accidentsare a result of driver error, and the use of autonomous features toreplace as great a percentage of the human driver (particularly thosewhere there is driver error) the greater the reduction in accidents.

Use of autonomous features during certain times of the day, and/orduring certain types of driving may also increase the rate reduction.For example, use of features during lazy Sunday drives may provide onereduction level, while the use of the same features during rush hour onmain roads may provide a higher rate reduction.

In modeling the use of autonomous features in a vehicle for providinginsurance premiums, a multi-variate algorithm may be used. Thisalgorithm may provide an exposure base and or a separate base rate, suchas one base rate with the autonomous features and another base ratewithout the features. Liability may be credited as between the two ratesbased on use of the autonomous features. The autonomous algorithm mayaccount for the environments that the vehicle is used in, as describedherein, and the various configurations of the vehicle. Snapshots ofclaims based on accidents may be used to hone the algorithm, includingthose claims for a single crash.

In either of the two base rate scenarios or the algorithm, a weightedmileage may be deducted from the metric to arrive at the appropriatepremium. By way of non-limiting example only, a vehicle having twoautonomous features may be used. A first feature of the two is activated66% of the time the vehicle is in use and provides a reduction ofpremium of 10%. The second of the two features is always on and isactivated when the vehicle is being operated at less than 20 miles perhour. The second feature provides a 25% rate reduction for any milesmeeting the speed criteria. For this particular example, the vehicle isoperated at less than 20 miles per hour for 10% of the miles driven. Inthis case, the two features may operate cumulatively. The first featureprovides a 6.6% rate reduction (66% of the time for a premium of 10%)and the second feature provides a 2.5% reduction (25% reduction 10% ofthe time). This vehicle may be eligible for a 9.1% discount on thepremium of the vehicle.

While the present discussion has generally focused on vehicles, such ascars, for example, the concepts may be equally applicable toautomobiles, boats, motorcycles, ships, commercial fleets, truckvehicles, and other insured items that may include autonomous featuresand other signatures associated with the insured items.

Additionally, the present system may be configured to cover a driver ina ride-share network. This may occur when a user of a vehicle drives thecar of another person and/or may occur when there is a central carservice, such as a Zipcar, for example. This may affect the pricing ofpremiums and coverage, and may be assessed using the tracking describedherein. For example, the vehicle may be tracked to determine whether thevehicle owner is driving, the borrower driver is driving, and the amountof autonomous driving that is occurring. Specifically, during a givenday, say the vehicle owner drives 75% of the miles and a borrower driverdrives the other 25%. Of those miles, there is a calculated 20%autonomous driving ratio distributed equally between the two drivers. Inthis situation, the rating for the vehicle is the perfect autonomousdriving score of 1 times the 20% that the autonomous driving occurs plusthe owner's driving score times 60% (75% driving for 80% of the time)plus the borrower's score times 20 (25% driving for 80% of the time).

Further, the vehicle may provide autonomous features where the vehicleis connected to weather data and based on the weather data moves intothe garage, for example. Alternatively, the vehicle may move to a saferlocation based on the weather data, for example. In either situation,the vehicle may monitor the weather information, and upon receipt ofinformation that requires movement, may turn itself on and move asappropriate to aid in protecting the vehicle. Such a feature may reducepremiums on comprehensive by avoiding hail damage and other types ofdamage that occur as a result of weather accidents.

Some examples described herein are associated with a scenario wherein anew customer registers for insurance and then the system 100 adjusts thepricing information based on telematics data. The systems and methodsdescribed herein may also be applied to current and former customers whoare looking to renew their coverage. In this scenario, the biographicalinformation and historical driver information may already be stored onthe insurance server 180, and the DPU 170 may access this informationdirectly.

In addition to the example information above, additional information maybe determined during or after the registration phase. For example, Table1 shows biographical information that may be used in generating driverrisk profiles.

TABLE 1 Additional Driver Information Primary Metric HouseholdComposition Presence of Married or Domestic Partners/Total Number ofDrivers Youthful Policy Composition Driver Age/Gender-Marital StatusDriver Age/Annual Mileage Limited Driving Driver Age/Driver TrainingDriver Age/Good Student Driver Age/Principal/Occasional Operator DriverAge/Years Licensed Vehicle Age*/Driver Age Driver Age/Prior BI LimitDriver Age/Number of Drivers Driver Age/Number of Vehicles Driver Age -Household Composition Primary Insured Age Primary Insured GenderSecondary Insured Age Primary and Secondary Driver Age DifferenceSecondary Metric Vehicle Age*/Number of Vehicles Annual Mileage VehicleUse Number of Renewal Years Safe Driver Insurance Plan Chargeableat-fault accidents - First Year/Subsequent Years Safe Driver InsurancePlan Minor violations excluding speeding - First Year/Subsequent YearsSafe Driver Insurance Plan Major violations excluding Driving WhileIntoxicated (“DWI”) - First Year/Subsequent Years Safe Driver InsurancePlan Minor violations - speeding only - First Year/Subsequent Years SafeDriver Insurance Plan Major violations - DWI only - FirstYear/Subsequent Years Usage Based Insurance Score

The system 100 may be configured to weight each factor based onactuarial date. For example, in the example above, there are twocategories, primary and secondary wherein each factor within aparticular category may be weighted equally. However, each factor may beassigned a unique weight.

The registration phase is used to generate an initial risk profile, asshown in Table 1, above. During the registration phase, the system 100receives biographical information about each of the drivers that may beassociated with the user's account as well information about thevehicles for which coverage is requested. With millions of accidentseach year, a large amount of data is available on factors that mayaffect the likelihood of an accident as well as the severity of theaccident. The database 176 associated with the DPU 170 containsinformation regarding accident information. The DPU 170, using amultivariate analysis, generates the initial driver profile based on theprovided biographic information verses the factors stored in thedatabase 176. Where allowable by law, one factor that may be used ingenerating the initial risk assessment is based on the zip code of theinsured's home/garaging address. For example, initial risk assessmentmay be based on a territory risk score assigned using the home/garagingzip code. The territory risk score is based on data such crime data,accident data, weather data etc. that might be considered as directexposure variables. An example of a low-resolution risk assessment isshown in Table 2.

TABLE 2 Initial Risk Assessment Percentage Time Stored in LocationLocation Location Risk Home 25 1 Office 40 1.5 Low Risk Locations 7.5  0-3.3 Medium Risk Locations 20 3.4-6.6 High Risk Locations 7.5 6.7-10 

As shown in Table 2, based on the entered biographical information, theinitial risk assessment is generated predicting the amount of time thevehicle 140 may be stored in various locations. The DPU 170 may beconfigured to determine the specific risk associated with the home andoffice locations entered by the user. Additionally, if a student islisted as a driver, the school may be added as an expected location. Thelist above is by no means exhaustive. Based on the entered biographicalinformation, the DPU 170 may also be configured to generate anexpectation on time spent in low risk, medium risk, and high risklocations (other than the specific expected locations). This informationmay be used to generate rate pricing information.

During the registration phase, the system 100 receives biographicalinformation about each of the vehicles and the expected drivers for eachvehicle and the percentage each driver is expected to use each vehicle.This may be used as a baseline to create vehicle profiles.

The inside of vehicle 140 may include a plurality of electronics devicesand sensors that may communicate information to the smartphone 110. Thevehicle 140 may include a microprocessor and memory that may operativelyconnect to each individual electronic device. For example, there may beelectronic devices associated with the seats, A/C units, GlobalPositioning Satellite (“GPS”)/stereo system, DVD unit, and BLUETOOTHequipment. The microprocessor may also be in communication with theheadlights, engine, traffic signals, rear view mirror, rearview cameras,cruise control, braking system and inner workings of a vehicle. Theremay also be additional devices such as multiple user devices 130 broughtby passengers into a vehicle. The smartphone 110 may be configured toreceive information from the electronics in the vehicle 140. Forexample, the smartphone 110 may be configured to receive or sense dataconcerning, speed, braking, location, seat settings, lane changes, radiovolume, window controls, vehicle servicing, number of cellular devicesin a vehicle, proximity to other vehicle's and their devices, etc. Thetelematics device may be configured to transmit the telematics datadirectly to the smartphone 110. The smartphone 110 may then format thetelematics data and transmit it to the DPU 170. The DPU 170 may use asoftware based algorithm to analyze the telematics data to identifydriving segments wherein each driving segment is associated with adriver signature. The DPU 170 may then categorize each signature as aknown or unknown driver. Wherein the DPU 170, a signature with driverslisted on the insurance, may associate. The DPU 170 may further beconfigured to categorize unknown driver signatures as potentiallyimpaired/distracted driving. The DPU 170 may compare the driversignatures with the expected drivers to determine the driver of avehicle for each determined driving segment.

The smartphone 110 may be configured to format the telematics data (e.g.provide a summary) to the DPU 170. Once the account has been activated,the DPU 170 may be configured to use this information to determine thedestination information associated with each vehicle.

The smartphone 110 may be configured to provide telematics dataperiodically as well as based on a trigger. In one embodiment, if thevehicle 140 is stopped for a predetermined period of time, or thevehicle 140 is turned off, idled, or otherwise stationary, thesmartphone 110 may be configured to transmit a signal identifying thelocation as a stopping point.

As shown below in Table 3, the DPU 170 may be configured to receive andstore location information associated with the vehicle 140 anddetermines destination information. Based on the reported locations, thesystem 100 may generate a database with information including stoppagetimes, the duration of the stoppage, the location of the stoppage, andother factors (e.g. phone in use.) The DPU 170 may be configured tostore map information, including nearby businesses and points ofinterest for each location. Alternatively, the DPU 170 may be configuredto communicate with third-party applications, such as GOOGLE® Maps,which contain location information about nearby businesses etc. The DPU170 may determine nearby locations (which may be possible destinationsfor the driver). The DPU 170 may also be configured to account for otherfactors, such as stopping for a phone call.

TABLE 3 Measured Destination Information Time Phone Nearby LocationBehavior Stopped Duration in Use Location Location Risk Risk 1:05 am 1:00 N 32606 Moe's 104 183 Tavern 2:35 am  5:02 N 32605 Home 100 1009:07 am  10:13 N 32611 Office 107 154 8:50 pm  0:14 Y 32951 Highway 155 75 1:09 am  75:12 N 32605 Home 100 121 4:43 pm 142:19 N 32601 Airport179 103

The DPU 170 may be configured to analyze the data using a multivariateanalysis. Based on the received destination information, the DPU 170 maycalculate a direct exposure risk rating and indirect exposure riskrating, where the direct exposure risk rating may comprise physicalrisks to the vehicle 140 based on the location and indirect exposurerisk rating may incorporate behavioral risks.

According to some embodiments, the direct risk exposure may compriseinformation based on the location risk, which may be affected by vehicledensity, lighting, outdoor/indoor parking, storing a vehicle in aneighborhood with a high number of break-ins or thefts, storing avehicle in areas with high numbers of uninsured drivers. The DPU 170 maybe configured to communicate with external servers 190 that may providedetailed crime information for predetermined areas (e.g. 1 meter).Additionally, the DPU 170 may communicate with external servers todetermine weather information and real-time traffic density andpedestrian density.

The DPU 170 may be configured using a multivariate analysis to comparethe destination information with the initial risk assessment. The RPU160 may access the database 176 associated with the DPU 170 to determineadjusted pricing information based on the destination information.

The direct exposure rating may be determined based on loss dataassociated with a location. The DPU 170 may generate a risk locationmap, wherein each location is assigned a score. At a macro level, thisscore may be assigned based on a zip code; however, the risk locationmap may be generated with more or less granularity. The duration andtime of day during which a vehicle is parked at a destination may beaccounted for in determining the direct exposure rating. Additionalfactors may also be accounted for, for example, whether the vehicle isin a garage or the weather associated with each location.

The system may use a multivariate analysis to generate the value of therisk. For example, parking a vehicle 140 in a location known for hailstorms may present a high risk of damage; however, if the vehicle 140 isinside a garage, the risk might be mitigated. Based on the home orgaraging location, cited by the user, a risk location map may beweighted to set the home location as a value of 100. An example of arisk location map is shown in Table 4:

TABLE 4 Risk Location Map Zip Score % of time parked 32605 100 0.3 32606104 0.1 32611 107 0.1 32951 155 0.1 32601 179 0.5

Each location in the risk location map is then compared with thehome/garaging location. During the registration phase, the system 100may only have received information regarding the home or garagingaddress; accordingly, the initial rate may have been based on thatsingle variable analysis. The DPU 170 may use the telematics data fromthe smartphone 110 to determine the time spent at each location, asshown in Table 4.

The DPU 170 may then calculate a direct exposure relativity accordingto: Direct exposure relativity=rates weighted by time spent in thelocation/rate of home location. The direct exposure relativity,calculated by the DPU 170, may also account for the time of day in whichthe vehicle is stored at a location. For example, parking in a hightraffic parking lot may be safe with respect to thefts during the daybut more likely to be involved in an accident. But at night, thelocation may be a high theft area. Accordingly, the direct exposurerelativity may further comprise weighting factors for the time of dayand duration for which a vehicle is stopped at a destination.

The system 100 may further access additional data to assess the risk ofa location for the vehicle 140; for example, the number of accidents orthefts in an area. As the amount of data increases, the system mayidentify a gradient of vehicle values in an area. Accordingly, a highvalue vehicle commuting to an area with predominantly low value vehiclesmay be considered an additional risk.

The indirect exposure rating accounts for behavioral patterns that maybe correlated with destinations. Studies have shown correlations betweenrisk appraisal and risky behaviors and the numbers of traffic offenses.Personality traits have been associated with the type of sensationseeking behavior that may result in accidents and therefore the filingof a claim.

Currently, speeding tickets are used to identify a propensity for driverspeeding. And propensity for speeding is used to calculate theexpectation of an accident or some event for which a claim is filed.However, the number of speeding tickets may not be indicative of theamount of risky behavior exhibited by a driver. For example, one drivermay travel at speeds a few mph over the limit on a heavily monitoredroad, whereas a second driver may speed 30 mph over the speed limit onan unmonitored road. In this scenario, the first driver may receive moretickets, while representing a lower insurance risk. The indirectexposure rating provides the insurance company with additional riskassessment data to further refine insurance rates.

The DPU 170 may be configured to compile information, regarding highrisk behaviors, based on the location to which a vehicle is driven. Forexample, a vehicle that is stopped at a sports stadium, during a biggame, the vehicle is more likely to be surrounded with a high number ofvehicles that are expected to start moving at approximately the sametime. The DPU 170 may contain statistical information that a person at asporting event is less likely to speed but more susceptible to a lowspeed fender bender. The DPU 170 may further contain statisticalinformation regarding whether a person attending sporting events is moreor less likely to be involved in reckless driving, or more or lesslikely to be involved in an incident in which a claim is filed.

The indirect exposure rating may further provide granularity and detailto the direct exposure rating. For example, a police impound lot may bedetermined to be a very safe location, based on the direct exposurerating. There may be a low chance of theft or other damage. However, theindirect exposure rating may account for this as being a risky behavior,since an impounded vehicle may be an indicator that the vehicle is notbeing properly monitored by the owner.

Accordingly, in addition to the risk location map, the DPU 170 may beconfigured with a behavior risk map that similarly charts out potentialbehavior risks associated with each location. An example of a behaviorrisk map is shown below in Table 5:

TABLE 5 Behavior Risk Map Location Nearby Location Behavior Risk 32606Moe's Tavern 183 32605 Home 100 32611 Office 154 32951 Highway  75 32601Airport 103

Using the behavior risk information and the time and duration a vehicle140 is stopped at a location, the DPU 170 may generate an indirectexposure score. For example, if the DPU 170 detects that a vehicle isparked near a Fenway Park 81 times a year, DPU 170 may indicate thispattern as an increased risk for dangerous behaviors.

The DPU 170 may further be configured to correlate this information withother bibliographical information. For example, biographical informationindicates that one of the insured individuals on the account works atsaid Fenway Park, and then the DPU 170 may determine that the behavioris not a high risk behavior.

To avoid “false positives” that indicate risky behavior, additionalmeasures may be put into place. For example, in the case someonefrequently visits a sporting venue, the system may contain measures thatavoid the chance of penalizing good Samaritans who may serve asdesignated drivers for their friends. Accordingly, if the risk factorassociated with the location is associated with poor driving afterwards,the system may be configured to monitor driving immediately afterleaving the class of location to determine impairment or noticeablechanges in driving signature.

The system 100 may further be configured to determine whether thevehicle 140 is a self-driving vehicle, in which an on-board computeroperates the vehicle. In this case, the effect of the indirect exposuremay be reduced when determining the pricing information.

The system 100 may use biographical information provided in web pages asa baseline for generating the initial pricing information. However, thetelematics data provided by the smartphone 110 may be used to refinethis information. The RPU 160 may access the information stored in theDPU 170, and use a software based algorithm to determine whether toadjust the rate or to assess a credit or penalty/surcharge.

In a first example, the system 100 may offer the user a predetermineddiscount to sign up for a telematics program. The system 100 may beconfigured to generate a discount factor, for example according toDiscount relativity=starting discount*β₁ρ₁*β₂ρ₂*β₃ρ₃ . . . β_(n)ρ_(n),where β is a weighting factor and ρ represents direct and indirectexposure ratings. For example, the starting discount may be 10%, and ifthe product of the direct and indirect exposure ratings with theweighting factors >1, the system 100 may determine the driver is noteligible for a discount.

The system 100 may identify the driver based on the seat and/or mirrorsettings of the vehicle. The DPU 170 may also identify the driver basedon the route or destination in which the vehicle 140 is travelling (forexample, based on the employment information, if the vehicle drives andparks for an extended time at an office, it may identify the driver).Alternatively or additionally, if a user device 130 is connected withthe vehicle 140 via BLUETOOTH, it may identify a phone number associatedwith the smartphone 110 or user device 130 and identify the driver basedon that information. To further enhance this data, if the user device130 is used for a phone call over the speaker phone, based on thelocation of the microphone that picks up the speech, the identificationof the driver may be determined more accurately using voice recognitiontechniques.

Some vehicles 140 may automatically adjust the driving position based onan electronic key that is used for entry into the vehicle or to startthe vehicle. The smartphone 110 may be configured to identify the keyused to activate the vehicle 140. Then, if the seat/vehicle settingremains the same, for example, the smartphone 110 may transmit thisinformation to the DPU 170 which is able to determine that the driver isthe same as the registered or expected key owner. If the seat/vehiclesettings are adjusted, then a DPU 170 may determine that a differentdriver is driving the vehicle 140.

In one embodiment, the DPU 170 may use the implicit driveridentification, based on telematics data, to identify the number ofunique driver signatures operating each vehicle and the amount of timeeach of the unique driving signatures are operating each vehicleincluding the vehicle driving or partially driving itself. The DPU 170may use this information to determine the number and identity of driversfor each vehicle on the policy. The DPU 170 may communicate thisinformation to the RPU 160, which may be configured to adjust thepricing information associated with the account. The pricing informationmay be adjusted, for example, by modifying the rate or rate categoryassociated with the account or by providing a discount or penalty to theprevious rate.

In another embodiment, the DPU 170 may be configured to access socialmedia information associated with the drivers, and this information maybe stored, for example on storage 192 associated with external servers190. For example, the DPU 170 may receive data from an external server190 associated with GOOGLE or FOURSQUARE or other similar application,which tracks an individual's location. The DPU 170 may be configured tocompare the checked in location with the location of the vehicle 140indicated by the smartphone 110 and thereby identify the driver.

In another example of implicit driver identification, the DPU 170 may beconfigured to determine the driver based on the location of the vehicle140. For example, if the vehicle 140 is driving to or parked at one ofthe insured's offices, the DPU 170 may identify the driver as aparticular person.

A telematics device might be configured to transmit explicit driveridentification information to the smartphone 110. The vehicle 140 may beequipped, for example, with biometric readers that explicitly identifythe driver. For example, to activate the vehicle 140, the driver maysubmit a fingerprint, retina sample, a voice sample or other similarbiometric data. The telematics device may be configured to transmit thisexplicit identification information to the smartphone 110.

The smartphone 110 is configured to sense and/or receive telematics datawhich is then formatted and sent to the DPU 170. The DPU 170 analyzesthe information and clusters the time into segments. The segments mayinclude time during which the vehicle 140 is being driven and time thevehicle 140 is parked. The DPU 170 may use telematics data and associatea driver or a driver signature with each driving segment. The RPU 160may use the driver signature information in a number of ways to adjustthe pricing information. The RPU 160 may be configured to assess riskassociated with coverage without identifying the driver, and only thedriving behavior. In this embodiment, the RPU 160 generates a riskassessment or profile, which may be based on the risk associated withinsuring the vehicle based on the vehicle and the driver signatures.

An example of the telematics data, stored and transmitted by asmartphone 110 is shown in Table 6, below. The smartphone 110 may beconfigured to include an event/status monitor of the vehicle's 140activities. An example of the event/status log, which may be stored in adatabase operatively coupled to the smartphone 110.

TABLE 6 Telematics Information Recorded Radio Turn- Turn Time SpeedAccel Volume Phone Location Brakes ing Signal 1:05 am 76 4 8 32605 1:06am 86 −6 8 Y 32605 Y 1:07 am 54 30 8 32606 1:08 am 86 −2 9 N 32606 Y Y N1:09 am 52 −30 9 32606

The smartphone 110 may be configured to take periodic measurementsregarding the vehicle, as well as event triggered measurements. Forexample, the smartphone 110 may be configured to take readings every 1second. The smartphone 110 may be configured with different intervalsfor each measurement, for example, while speed may be reported everysecond, the radio volume may be reported each minute. The smartphone 110may be configured to receive this information and format the informationto the specifications required by the DPU 170. Additionally, thesmartphone 110 may be configured to take readings based on eventtriggers, such as a detected turn, brake event, and phone activation,etc. The example above is not exhaustive; the metrics are shown asexample only.

In another embodiment, the smartphone 110 or DPU 170 may be configuredto determine when a braking event occurs. In this example, thesmartphone 110 or DPU 170 may be configured to analyze speed andacceleration information to determine whether a braking event occurred.For example, if the acceleration data is below a threshold, a brakingevent may be declared. Similarly, if the positioning of the vehicle 140,relative to a determined center line of a road veers, the smartphone 110or DPU 170 may determine a turn event, a lane change event, or impaireddriving. This information is received, by the DPU 170, which may thenperform analysis to determine driver signatures (or this function mightinstead be performed by the smartphone 110).

Based on the type of plan, the RPU 160 may access the database 176associated with the DPU 170 to determine risk and pricing information.The RPU 160 may determine the pricing based on the percentage of timeeach vehicle is driven by a particular driver. The DPU 170 may associateeach driving segment, based on the driver signature of that segment,with a driver. After associating each driving segment for a vehicle 140with a driver, the DPU 170 then calculates percentages of vehicledriving time to apportion to each driver.

The system 100 may use the information provided via a web page togenerate an initial vehicle usage profile for each of the listed driversincluding the vehicle itself. However, the telematics data, such asinformation provided by the smartphone 110, may also be used to refine,replace, or adjust this information including replacing a proxy forautonomous feature usage with actual feature usage. The DPU 170 may usethe information received from the smartphone 110 to estimate the totaluse time for a vehicle 140. The system 100 may, for example, categorizeeach segment as being driven by a known driver (i.e. listed on theinsurance) or an unknown driver (i.e. third-party or impaired diver).Table 7 shows an example of a usage chart generated by the system 100.

TABLE 7 Vehicle 1 Vehicle 2 John Doe  80% 10% Jim Doe  19% 40% UnknownDriver 1 0.5% 50% Unknown Driver 2 0.5%  0%

As shown in Table 7, the system 100 may be able to identify individualdrivers. The unknown drivers may indicate that the vehicle 140 is beingoperated by an impaired driver, a distracted driver or unregistereddriver. Additionally, it may indicate that the vehicle is being movedvia a tow truck. Based on the received information, the DPU 170 mayidentify unique driver signatures and categorize the use of eachvehicle. The DPU 170 may identify these driver signatures by clusteringdriving characteristics into segments using a multivariate analysis. TheDPU 170 is configured to weight the information, based on the source(e.g. implicit driver identification, explicit driver identification).For example, if biometric readings provide explicit driveridentification information, the likelihood of accurate driveridentification is higher; it may therefore be weighted higher in thealgorithm that determines the likely driver at each time. Implicitidentification of a driver may be less accurate; accordingly eachimplicit identification may be weighted lower. For example, if Jim Doeis 6′8 and John Doe is 5′5, and the smartphone 110 or DPU 170 has accessto seat adjustment information, it may compare the seat placement versusthe height of the drivers. In this case the driver settings may providea reliable indicator of the driver. However, braking, driver speed maybe less likely an indicator in certain circumstances.

The RPU 160 may determine pricing information for the account, forexample, based on an adjusted rate or a credit or penalty based on thisinformation. For example, if the amount of driving segments that areidentified as impaired, distracted or unregistered are above apredetermined threshold, the RPU 160 may determine that the pricinginformation should be adjusted.

The system 100 may further be configured to proactively adjust pricinginformation based on detected high risk behavior. For example, if theDPU 170 determines that the amount of impaired, distracted orunregistered driving is below a predetermined threshold, or if thesignature associated with a high risk driver improves or is reducedrelative to one or more vehicles.

In another embodiment, the RPU 160 may assign risk, agnostic of thedriver, based on the driving signatures. In this example, the RPU 160requests data from the DPU 170 regarding the driving characteristics.Each use of the vehicle is categorized. For example, see Table 8:

TABLE 8 Categorization of Use Vehicle 1 Vehicle 2 High Risk Use 25% 55%Medium Risk Use 25% 35% Low Risk Use 50% 10%

Based on the amount of time the vehicle is driven in each risk category,the RPU 160 may determine pricing information without needing toidentify the number of drivers or the identity of those drivers.

A registration phase may be used to generate an initial risk assessment.During the registration phase, the system 100 receives biographicalinformation about each of the drivers that may be associated with theuser's account as well as information about the vehicles for whichcoverage is requested. With millions of accidents each year, a largeamount of data is available on factors that may affect the likelihood ofan accident as well as the severity of the accident. The database 176associated with the DPU 170 contains information regarding accidentinformation. The DPU 170, using a multivariate analysis, generates theinitial driver assessment based on the provided biographic informationverses the factors stored in the database 176.

The DPU 170 may perform a correlative analysis on the enteredbiographical information to develop the initial risk assessment whichmay be based in part on the expected speeding, the expectedacceleration, the expected turns, the expected braking, the expectedmileage driven, the times of day driven, etc. The list above is by nomeans exhaustive. Based on the entered biographical information, the DPU170 may also be configured to generate an expectation on time spent inlow risk, medium risk, and high risk locations (other than the specificexpected locations). The RPU 160 may use this information to generatepricing information. For example, the RPU 160 may adjust the rateassociated with an account, it may credit or debit a rate and/or todetermine adjusted pricing information.

The inside of vehicle 140 may include a plurality of electronics devicesthat may communicate information to the smartphone 110. Most vehiclesinclude at least one microprocessor and memory that connects to eachindividual electronic device. For example, there may be electronicdevices associated with the seats, A/C units, GPS/stereo system, DVDunit, and BLUETOOTH equipment. The microprocessor may also be incommunication with the headlights, engine, traffic signals, rear viewmirror, rearview cameras, cruise control, braking system and innerworkings of the vehicle 140. The smartphone 110 may, according to someembodiments, be configured to receive information from the electronicsin the vehicle 140. For example, the smartphone 110 may be configured tosense or receive data concerning, speed, acceleration, turns, braking,location, seat settings, lane changes, radio volume, window controls,vehicle servicing, number of cellular devices in a vehicle, proximity toother vehicles, etc.

The smartphone 110 may format this information and transmit it to theDPU 170. Once the account has been activated, the DPU 170 may beconfigured to use this information to determine the relativity factorsassociated with each vehicle.

The smartphone 110 may be configured to record telematics dataperiodically as well as based on a trigger. Based on this information,the DPU 170 may be configured to determine a plurality of relativityfactors for the measured data categories. In one embodiment, therelativity factors may be based on predetermined road segments.

For example, the DPU 170 may also be configured to categorize portionsof road as road segments, wherein road segments may be predeterminedlengths of road. As a preliminary basis, the DPU 170 may label a firstcategory of roads “highways,” including: interstates, U.S. highways,limited-access highways as “highways” or “primary roads.” The DPU 170may label a second category of roads as “urban,” including: secondaryroads, and local roads of high importance. The DPU 170 may label a thirdcategory of roads as “other,” including: local roads of minorimportance, alleys, other unpaved roads or footpath. Alternatively oradditionally, the DPU 170 may be configured to determine the relativityfactors in relation to nearby drivers or drivers on similar roads undersimilar conditions.

In a first example, the DPU 170 may be configured to determine a drivinglocation relativity factor. For example, the driving location relativityfactor may credit or penalize a driver for driving in locations more orless risky than their home address. The database 176 of the DPU 170 maygenerate a Driving Location Risk Index (“DLRI”), wherein the DLRIcomprises rankings of each driving location, a vehicle may encounter.The DLRI may be based on a predetermined area. This granularity may beadjusted based on the available telematics and loss data. As oneexample, where allowable by law, the DLRI may be categorized by zipcode. After receiving telematics data from the smartphone 110 of vehicle140, the DPU 170 may be configured to compare the driving location, withthe DLRI to determine the relative risk of the locations.

For example, the DPU 170 may calculate the relative risk of the reportedlocations actually driven compared to the expected home locationaccording to the procedure described below. The DPU 170 may determinethe total number of miles driven by zip code. Next, the DPU 170 maycalculate a state adjustment factor. The state adjustment factor may becalculated, e.g. according to State adjustment factor=State Avg.Premium/State Avg. Base Rate wherein the state adjustment factor isbased on bodily injury, property damage, comprehensive and collisioncoverage factors. The DPU 170 may use the state adjustment factor tocalculate adjusted base rates by zip code, based on Adjusted Base Ratesby Zip Code=State Adjustment Factor×Base Rate. The DPU 170 may use thisinformation to generate adjusted base rates for each of the locations.An example of weighted average rates, based on the driving location, isshown in Table 9.

TABLE 9 Weighted Average Rates ZIP Miles Rate 10001 30% 100 10002 10%130 10003  5% 150 10004 (home) 25% 125 10005 30% 240

Based on the percentage of miles driven in each zip code, a rate isdetermined. The driving location relativity is determined according toDriving location relativity=Sqrt(wtd avg of rates/rate of home zip,where a DLRI >1 indicates that the vehicle is driven in riskier areasthan the home location. A DLRI <1 indicates that the vehicle is drivenin less risky areas than the home location.

The DPU 170 may further be configured to generate a braking relativityfactor. To generate a braking relativity factor, the DPU 170 mustdetermine if a predetermined condition is satisfied such that a brakingevent is declared. For example, the DPU 170 may declare a braking eventbased on a rate deceleration or the amount of pressure applied to abrake. The database 176 of the DPU 170 may further be configured tostore braking benchmarks for each type of road segment. An example ofthe braking benchmarks is shown in Table 10.

TABLE 10 Benchmark Braking Threshold Benchmark Braking Threshold (*Basedon Road Segment Median, **Based on 75th Percentile) Highway 0.01brakes/mile* Urban 0.07 brakes/mile** Other 0.03 brakes/mile**

Based on received telematics data, the DPU 170 determines the frequencyand location of each braking event. This information is compiled in thedatabase 176, and the DPU 170 then determines the amount of brakingevents per mile for each type of road segment and the overall proportionof braking for each road segment. Table 11 shows an example of compiledbraking data.

TABLE 11 Compiled Braking Data Road Segment Braking Events MilesProportion Highway 0.12 brakes/mile 2640 0.46 Urban 0.29 brakes/mile1650 0.29 Other 0.32 brakes/mile 1430 0.25

For each type of road segment, an index is determined, wherein theindex=measured/benchmark. For the example above, HW_Index=0.12/0.01,UR_Index=0.29/0.07=4.1, and OT_Index=0.32/0.03.

The DPU 170 may be configured to calculate an overall breaking index byaveraging each of the braking indices weighted by the proportion ofmiles driven on each road. In the example above, the overall brakingindex may be calculated asOverall_Braking_Index=HW_Index*prop_miles_driven_HW+UR_index*prop_miles_driven_UR+OT_Index*prop_miles_driven_Other.The DPU 170 may be configured to rescale the overall braking index andcenter it on 1. This overall braking index may be scaled according tothe following equation: Scaled Braking Index=(Overall_Braking_Index−meanof the distribution)/(standard deviation of the distribution)+1 whereinthe mean and standard deviation of the distribution come from a lookuptable.

The system 100 may be able to adjust pricing data with or without lossdata. For example, in absence of enough credible loss data fromtelematics devices, (enough losses in the data to have desiredstatistical power), the system 100 may determine an expected loss value,also known as Expected Pure Premium (“EPP”) to calculate a brakingrelativity factor, wherein the EPP is calculated based on conventionalclass plan variables. The EPP may then be regressed on the telematicsvariables like braking, speeding etc. in a multivariate scenario toderive coefficients for these telematics variables. In anotherembodiment, the system 100 may use a univariate analysis and the EPP maybe used to calculate the slope for the telematics variable. Using a lookup table, stored in database 176, the DPU 170 may map the scaled brakingindex to a braking relativity factor. An example of mapping a scaledbraking index to a braking relativity factor is shown in Table 12.According to the Table 12, an expected pure premium may be used.

TABLE 12 Braking Relativity EPP Based Braking Relativity (Square root ofRaw EPP Relativity) **From EPP Scaled Braking Index Relativity Look UpTable 0.9  0.97 1.0 1.0 2.0 1.3

The DPU 170 or smartphone 110 may further be configured to determine aspeeding relativity factor. The database 176 of the DPU 170 may bepreconfigured to store a speed benchmark for each road segment. Table13, below shows an example of a speed benchmark, using the same segmentsdetermined for the braking benchmark. This is used as an illustrativeexample only. In another embodiment, the road segments for speed may bedetermined based on posted speed limits, or measured clustered drivingpatterns.

TABLE 13 Benchmark Speeding Threshold Road Segment Benchmark Highway 75mph Urban 25 mph Other 45 mph

After receiving the telematics data, the DPU 170 may be configured tocalculate the proportion of miles driven 20 mph over the speedbenchmark, 10 to 20 mph over the speed benchmark, 1 to 10 mph over thespeed benchmark and 0 mph over the speed benchmark for each of the typesof road segment. Further, the DPU 170 may be configured to assignweights based on the variance from the speed benchmark. An example forhighway segments is shown in Table 14, below. While the table below onlyshows weights for speed above the speed benchmark, it may also includeweights for speeds below the speed benchmark.

TABLE 14 Compiled Speed Data for Highway Segments Segment MilesProportion Risk Weight HW 20 mph over 39 0.01 100 HW 10 to 20 mph over280 0.11 85 HW 0 to 10 mph over 768 0.29 65 HW 0 over 1552 .59 35

The DPU 170 calculates a speeding index for each road segment bymultiplying the risk weight of each speed grouping (e.g. HW_20 mph over)by the proportion of miles within that bucket. For example, based on thethree equations given below:

HW_Index=Highway_20_mph_over_prop*wt+Highway_10to20_mph_over_prop*wt+Highway_0to10_mph_over_prop*wt+Highway_0_over*wt

UR_Index=UR_20_mph_over_prop*wt+UR_10to20_mph_over_prop*wt+UR_0to10_mph_over_prop*wt+UR_0_over*wt

OT_Index=OT_20_mph_over_prop*wt+OT_10to20_mph_over_prop*wt+OT_0to10_mph_over_prop*wt+OT_0_over*wt

The DPU 170 may further generate an average of the speeding indicesweighted by proportion of miles driven on each road segment to determinean overall speeding index, whereinOverall_Speeding_Index=HW_Index*prop_miles_driven_HW+UR_Index*prop_miles_driven_Urban+OT_Index*prop_miles_driven_Other.The DPU 170 may further be configured to determine an overall speedingindex that is used to determine the speeding relativity factor. Table 15shows an overall speeding index mapped to a speeding relativity factor.

TABLE 15 Speeding Relativity Factor Mapping Overall EPP Based SpeedingRelativity (Square root Speeding of Raw EPP Relativity) * From EPP IndexRelativity Look Up Table 80 100 100 106 115 113

The DPU 170 may further be configured to determine a mileage relativityfactor. The mileage relativity factor may be based on an expectedmileage value entered by the user during the registration phase. Theexpected mileage is compared with the measured mileage. The DPU 170 maymitigate the effect of the relativity factor, for example by operatingon the result with a function. As an example, the mileage relativity maybe calculated as follows, using a square root function to mitigate theeffect: Mileage relativity=SQRT(mileage factor based on actual milesdriven/mileage factor based on reported miles).

The DPU 170 may further be configured to determine a time of dayrelativity factor. Based on loss data, the DPU 170 may categorize timesegments as high risk, low risk and moderate risk. The DPU 170 maymeasure the relative risk of driving at certain times of day. The DPU170 may weight each of the times of day, wherein the weighting rewardslow risk miles while incrementally penalizing moderate and high riskmiles. Based on the received telematics data, the DPU 170 may furthercalculate the proportion of miles driven within each time of daysegment. Table 16 shows an example of time of day weighting.

TABLE 16 Showing Risks and Weights used for TOD Relativity Time of DayProportion of Miles Risk Weight High Risk 0.1 130 Moderate Risk 0.6 100Low Risk 0.3 75

The DPU 170 may then calculate a Time Of Day (“TOD”) risk index based onthe mileage weighted average of TOD risk. The TOD risk index is mappedto a TOD relativity factor, using a lookup table. Table 17 shows a TODrisk index and TOD relativity factor based on the example above.

TABLE 17 Time of Day Relativity Factors TOD EPP Based TOD Relativity(Square root of Risk Raw EPP Relativity) * From EPP Relativity IndexLook Up Table 80 0.90 110 1.1 140 1.3

The DPU 170 may transmit the relativity factors to the RPU 160. The RPU160 may be configured to adjust the rate, or provide a discount orsurcharge based on the relativity factors according to, for example:Discount relativity=starting discount*driving locationrelativity*braking relativity*speeding relativity*mileagerelativity*time of day relativity. The system 100 may further beconfigured to determine whether the vehicle 140 is a self-drivingvehicle, in which an on-board computer operates the vehicle 140. In thiscase, the effect of the driving time of day or any other factor may bemitigated when determining the pricing information.

The system 100 may use biographical information provided in web pages asa baseline for generating the initial pricing information. However,using the methods described above and the received telematics data,provided by the smartphone 110, the system 100 may refine the pricinginformation by adjusting the rate, providing a credit or surcharge, orrejecting a renewal. In one embodiment, the RPU 160 may access theinformation stored in the DPU 170 and the determined discountrelativity, and use a software based algorithm to determine a discount.

For example, the starting discount may be 10%, and if the product of thedirect and indirect exposure ratings with the weighting factors >1, thesystem 100 may determine the driver is not eligible for a discount.

In one scenario, the system 100 may receive telematics data for a fixedtime period. In this scenario, the RPU 160 may be configured tocompensate for the limited duration of the telematics data using aseasonality factor. For example, if the telematics data is received fromSeptember through December, and the biographical information indicatesone of the insured drivers attends college away from home, RPU 160 maybe configured to use the seasonality factor to adjust the pricinginformation to account for the lack of information transmitted regardingthat driver. Conversely, under the same scenario, if the readings weretaken during the summer, when the student was home, the telematics datamay be skewed the other way. Accordingly, the RPU 160 may use theseasonality factor to account for those differences.

The system 100 may further be configured to provide discounts outsidetypical renewal periods. For example, if an account includes a studentdriver and that student driver is associated with a high risk driversignature. If that student goes away to college, and the absence of highrisk driver signature is measured for a predetermined period of time,then the system 100 may be configured to confirm that a driver has movedout and may offer an immediate discount.

In another embodiment, the system 100 may be configured to transmit thedriver signature information to the customer. This may allow a customerto identify high risk driving behaviors and adjust the behaviors tolower their premium. This information may be accessible, for example,through web site system 120, or through an app loaded onto a user device130.

FIG. 7 shows an example 700 configuration for determining a driversignature based on telematics data. As shown in FIG. 7 , a driver issituated in the vehicle 140. The vehicle 140 includes an electronic seatadjustment unit 715 and a radio 720. The driver of the vehicle 140 alsohas a mobile device 710. In this embodiment, the mobile device 710includes an app that enables it to operate as the telematics device. Themobile device 710 may be connected to the vehicle 140 using a BLUETOOTHcommunications link. The mobile device 710 senses or receives seatposition information, route information, radio station information, andother telematics data from the vehicle 140. The mobile device 710 maycommunicate this information to a telematics collection server. Thisinformation may be communicated continuously during the vehicle's 140operation, or in another embodiment the mobile device 710 may beconfigured to transmit the information at scheduled times, for example,when the mobile device 710 is connected to a Wi-Fi network. Thetelematics collection server receives this information and may formatthe telematics data and send it to the DPU 170. The DPU 170 compares thereceived telematics data with preconfigured expected telematics values.As shown in FIG. 7 , the seat position information is compared with theexpected seat position and it is determined that this is indicative ofDriver A. The mobile device 710 recording the information is determinedto be indicative of Driver A. The route driven by vehicle 140 isindicative of Driver A. The use of radio 720 is determined to beindicative of driver A. While in this example, each factor is indicativeof driver A, in other examples, the seat position may be indicative of aDriver C and radio station may be indicative of a Driver B, by way ofexample. The DPU 170 may use a multivariate analysis to identify thedriver of the vehicle 140 for a particular trip based on this receivedtelematics information. Additionally, if all of the insured drivers areregistered with the system 100, and if vehicle usage shows extendeddriving periods, not accounted for by the data transmitted by the mobiledevices (e.g., 710), the system 100 may determine the use is by anunregistered driver. In the example shown in FIG. 7 , the DPU 170determines the driver to be driver A.

If the user is a potential customer, the user may provide or uploadinformation from past experiences to the system 100. Or they may enrollto receive a trial telematics smartphone application prior to receivingan initial quote.

FIG. 8 shows an example 800 configuration for determining a driversignature based on telematics data that accounts for a seasonalityfactor. As shown in FIG. 8 , a mobile device may be configured tocommunicate the telematics data as discussed in reference to FIG. 7 . Inthis example, telematics collection server may further be configured tocommunicate the date during which the vehicle was driven. This may beimportant, for example, if a student driver only drives 5% of the time,but that 5% of the time is during a snowy season. Additionally, asdiscussed above, the RPU 160 may incorporate a seasonality factor tocompensate for expected changes in driving patterns during differenttimes of year (e.g. different schedules during the school year). Thesystem 100 may be configured to use additional telematics data, forexample, received from third-party systems that may include weatherdata, traffic data, and other relevant data in compensating forseasonality.

Illustrative examples of the system 100 implementing driver signaturesare shown below. In a first scenario, the number of vehicles covered bythe policy may include the number of listed drivers. Table 18 shows adriver proxy score below:

TABLE 18 Driver Proxy Score Assigned by Insurance rating AssignmentDriver Proxy Score (1-50) Vehicle 1 Driver 1 30 Vehicle 2 Driver 2 45

In the example shown in Table 18, based on the information received fromthe customer, the assigned score is based on the expectation thatvehicle 1 will be driven 100% by driver 1 and vehicle 2 will be driven100% by driver 2.

However, the DPU 170 may receive telematics data to determine the actualmiles driven by each driver. Table 19 below shows the determined actualmiles driven.

TABLE 19 Actual Miles Driven, as determined by telematics data Driver 1Driver 2 Vehicle 1 80% 20% 100% Vehicle 2 20% 80% 100%

The DPU 170 may be configured to generate a weighted average of driverscore for vehicle 1 using driver signature=(percentage of time driven bydriver 1)(driver proxy score)+(percentage of time driven by driver2)(driver proxy score). The DPU 170 may further generate a weightedaverage of driver score for vehicle 2, for example, using as driversignature=(percentage of time driven by driver 1)(driver proxyscore)+(percentage of time driven by driver 2)(driver proxy score).Based on this information, the DPU 170 determines a driver signaturerelativity for each vehicle=actual/expected. The RPU 160 may use thedriver signature relativity to determine pricing information. In oneembodiment, the RPU 160 may generate a blended rate, based on the driversignature relativity. Additionally or alternatively, the RPU 160 may beconfigured to adjust the rate or provide a credit or penalty to theaccount. In another scenario, the number of vehicles may be greater thanthe number of drivers.

Based on the customer provided biographical information, the DPU 170 maydetermine a driver proxy score for each vehicle. Table 20 shows anexample of driver proxy scores in the scenario where there are morevehicles than drivers.

TABLE 20 Driver Proxy Scores when Vehicles > Drivers Assigned by DriverProxy conventional rating Assignment Score (1-50) Vehicle 1 Driver 1 30Vehicle 2 Driver 2 40 Vehicle 3 Driver 2 40

Based on the information received during the registration phase (oralternatively on past experience), in the More Cars Than Drivers(“MCTD”) scenario DPU 170 assigns a score based on an assumption thatvehicle 3 will be driven 100% by driver 2, the worse of the two drivers.Table 21 shows the determined actual miles for each vehicle by eachdriver.

TABLE 21 Actual Miles Driven when Vehicles > Drivers Driver 1 MilesDriven Driver 2 Miles Driven Vehicle 1 80% 20% 100% Vehicle 2 30% 70%100% Vehicle 3 50% 50% 100%

Based on this information, the DPU 170 may determine the weightedaverage of driver score for vehicle 1 using driversignature=0.80*30+0.20*40. The DPU 170 may determine the weightedaverage of driver score for Vehicle 2 using driversignature=0.30*30+0.70*40. The DPU 170 may determine the weightedaverage of driver score for Vehicle 3 using driversignature=0.50*30+0.50*40. The DPU 170 uses this information todetermine a driver signature relativity adjustment for eachvehicle=actual/expected. The RPU 160 may use the driver signaturerelativity to determine pricing information. In one embodiment, the RPU160 may generate a blended rate, based on the driver signaturerelativity. Additionally or alternatively, the RPU 160 may be configuredto adjust the rate or provide a credit or penalty to the account.

The system 100 may further be configured to account for technologiessuch as “driverless car technology,” which may allow for autonomousoperation of a vehicle, or aspects of a vehicle. The autonomous drivermay be controlled by the vehicle's 140 control system. In oneembodiment, the system 100 may be configured with a predetermined scorefor a driverless system. This may include scoring route selectionpatterns, braking patterns, accelerating patterns, and the speed,proportionality and accuracy of the vehicle's response to theenvironment, such as obstacles and changing conditions. The automatedsystem would be treated as a unique driver with a particular signatureattached. The system 100 may then be configured to account for the timea vehicle 140 is driven by a driverless vehicle system.

TABLE 22 Autonomous Vehicles Assigned by conventional rating AssignmentDriver Proxy Score (1-30) Vehicle 1 Autonomous 1 (Perfect Driver Score)Vehicle 1 Driver 1 5 (Good Driver Score) Vehicle 1 Driver 2 20 (BadDriver Score)

An assigned score in the example of Table 22 assumes a vehicle 1 willautonomously operate itself, thereby earning a perfect driver proxyscore (no accidents). However, driver 1 and driver 2 can assumeoperation of the vehicle. This would override autonomous capability andtherefore the pricing calculation could be modified by a relativityfactor. This factor would be calculated as follows for 80% autonomousdriving, driver 1 a 15% driving, and driver 2 a 5% driving. Weightedaverage driver score for vehicle 1 using driversignature=0.80*1.0+0.15*5.0+0.05*20=2.55. Therefore, the driversignature relativity for vehicle 1 equals the actual/expected which is2.55/1=2.55. This relativity factor can then be used in the calculationof the premium for vehicle 1.

FIG. 9 shows three examples 900 of expectation based processing. Asshown in FIG. 9 , the three drivers may all be drivers of the samevehicle 140. The drivers include different genders, ages, credit rating,etc. Based on the initial biographic information, the DPU 170 determinedan expectation of driver behavior. In the example shown, the DPU 170determined expected values for speeding, braking, driving late at night,driving in traffic, lane changes and total mileage. The speeding,braking, driving late at night, driving in traffic and lane changes permile are all represented in relative terms. The driver is evaluatedagainst a hypothetical baseline driver. The expected values aredetermined based on the differences of a driver in a risk class versusthat baseline driver. The DPU 170 receives telematics information,either directly from a telematics device, or indirectly through athird-party operated system. In the examples shown in FIG. 9 , thereceived telematics data is summary data for the factors shown in thetable. The DPU 170 compares the measured behavior to the expectation. Asshown in FIG. 9 , Driver A is expected to brake, speed and change lanesfar more often than the hypothetical baseline driver. The actual valuesshow that while Driver A is in fact worse than the hypothetical baselinedriver, the difference is not nearly as much as expected. The RPU 160receives the comparison information related to Driver A, and determinesthat Driver A is in line for a lower premium. The RPU 160 may beconfigured to determine a new rate for the driver or it may keep thesame rate, but provide the driver with a credit. Driver B is expected tobe a better driver than Driver A. Driver B's measured behavior issimilar to Driver A, but Driver B does not get a discount. This isbecause Driver B was expected to be better than Driver A. As shown inFIG. 9 , the measured behavior of Driver B is very close to theexpectation. The RPU 160 may be configured with a threshold wherein ifthe measured driving behavior is within a predetermined value of theexpectation, it may not change the premium. In the example shown in FIG.9 , the variance of Driver B from the expectation for Driver B, that thepricing information is not changed. The measured behavior associatedwith Driver C is worse than the expectation; accordingly, the RPU 160determines a new premium that is higher, which reflects the higher riskassociated with that driver's driving behavior.

In another example of expectation based rating, a Driver Proxy Score(“DPS”) may be derived from a combination of rating variables in aconventional class plan. Table 23, below, shows an example of a driverproxy score.

TABLE 23 Driver Proxy Score Driver Proxy Age Sex Marital Credit Score(DPS) Driver 1 16 M U Good 25 Driver 2 45 F M Excellent 10

The DPU 170 may receive the telematics data and generate a DriverTelematics Score (“DTS”). Table 24 shows an example of a drivertelematics score.

TABLE 24 Driver Telematics Score Driver Miles Telematics SpeedingBraking Driven Score (DTS) Driver 1 Average Average Low 12 Driver 2Average Average Low 12

The DPU 170 may standardize the risk scores in Tables 23 and 24 usingmultivariate statistical techniques, to make them comparable on the samerisk scale. An Expectation Based Rating (“EBR”) may be calculated asfollows EBR for Driver 1=actual/expected=12/25=0.48 and EBR for Driver2=actual/expected=12/10=1.2.

As shown, by the scores above, two drivers with the same DTS may receivedifferent EBRs based on their expected behavior from a conventionalclass plan. Driver 1 may receive a discount as the actual drivingbehavior is better than expected whereas Driver 2 may receive asurcharge as the actual driving behavior is worse than expectation.

FIG. 10 shows an example 1000 of a location risk map used fordestination based underwriting. As shown in FIG. 10 , the vehicle 140 ismonitored as it visits multiple destinations. In FIG. 10 , the vehicle140 is shown stopped at four destinations. When the DPU 170 determinesthat a vehicle is stopped for a predetermined duration, the DPU 170identifies a location as a destination. As shown in FIG. 10 , the DPU170 may include a category for each destination. Each destination mayfurther be assigned a location risk rating. As shown in FIG. 10 , thestadium has the highest risk rating (190) and the library has the lowestrisk rating (84). The DPU 170 determines a risk score based on the riskrating of destination, the duration of stay at each destination, as wellas the time of day during which the vehicle is stopped at eachdestination. The DPU 170 may then compare this versus the home/garaginglocation, to determine a risk assessment. This risk assessment is usedby the RPU 160 to determine updated pricing information.

In another example of destination based underwriting, the DPU 170 may beconfigured to determine a Proxy Destination Score (“PDS”) based on aterritory rating based on the reported home/garaging address reported atthe time of sale of the policy. An example of a PDS is shown below inTable 25.

TABLE 25 Proxy Destination Score Home/Garaging Zip Proxy DestinationScore (PDS) 32951 42

The DPU 170 may use the received telematics data to generate aTelematics Destination Score (“TDS”), for example, based on thetechniques explained above. The DPU 170 may further calculate the amountof time spent at the destination, in the aggregate, over the total timeof a predetermined period (e.g. a month, six months). An example of aTDS is shown in Table 26.

TABLE 26 Telematics destination score (TDS) Telematics Destination % oftime at a destination Zip Score (TDS) within the location 32605 11 0.332606 12 0.1 32611 19 0.1 32951 42 0.4 32601 13 0.1

The DPU 170 may be configured to standardize the risk scores in bothTables 25 and 26 using multivariate statistical techniques to make themcomparable on the same risk scale. The DPU 170 may then determine adestination relativity score, as follows: Destinationrelativity=Weighted avg. of rates by time spent in the locationunit/home locationrate=11*0.3+12*0.1+19*0.1+42*0.4+13*0.1/42=Destination Relativity. Thedestination relativity may be compared with the expected value todetermine whether to adjust the pricing information or continuecoverage. For example, based on the determination relativity, the RPU160 may increase or decrease the rate and/or provide the account with acredit or penalty.

FIG. 11 shows an example visual flow diagram 1100 of an embodiment of asystem for telematics based underwriting. As shown in FIG. 11 , a driveris driving vehicle 140. The vehicle 140 may include multiple electronicsdevices configured to communicate with a smartphone located in thevehicle. The smartphone may sense speed, acceleration, etc. andcommunicate this information to a third-party operated server. Thesmartphone 110 may also be configured to receive raw telematics data andconvert it into a different format, e.g. summary telematics data. Thesmartphone 110 may communicate this telematics data in a predeterminedformat to the DPU 170. FIG. 11 shows an algorithm, implemented in theDPU 170 calculating a plurality of relativity factors. The RPU 160 mayuse these relativity factors to determine pricing information. A websitesystem may be used to communicate this pricing information to thesmartphone 110 or other user device 130, in the form of a web page. Asseen in FIG. 11 , the user device 130 may include a display that ispresenting the user with a discount. In another example, the display mayinclude information that compares the vehicle usage on the policy toother similar vehicles and/or drivers of a similar background. Thedisplay may further include suggestion regarding how to improve drivingto receive a discount or lower rate.

FIG. 12 shows a flow diagram for a method 1200 for determining driversignatures associated with vehicle use and updating pricing informationbased on the determined driver signatures. This application incorporatesthe entire contents of U.S. patent application Ser. No. 14/518,750,filed Oct. 20, 2014, and U.S. patent application Ser. No. 14/145,142,filed Dec. 31, 2013 by reference as if fully set forth. Because theinsurance company may employ a different analysis based on the number ofcars relative to the number of drivers, the system 100 may determine thenumber of vehicles and the number of drivers (S1210). Based on thenumber of vehicles and the number of drivers and the expected use ofeach vehicle, the DPU 170 may determine a driver proxy score for eachvehicle (S1220). A telematics collection server may then receivetelematics data sensed by a smartphone associated with each vehicle(S1230). The telematics collection server may be operated by theinsurance company or it may be operated by a third-party service. Foreach segment during which a vehicle is driven, the DPU 170 may analyzethe telematics data to determine a driver signature associated with eachsegment (S1240). The DPU 170 may determine the amount of time eachvehicle was driven by each driver signature (S1250). Based on thisinformation, the DPU 170 may generate a driver signature relativityfactor for each vehicle (S1260). The driver signature relativity factormay account for the driver proxy score for each vehicle verses thevalues determined based on driver signatures. The RPU 160 generates arisk assessment based on the driver signature relativity factor (S1270).In one embodiment, the risk assessment may include vehicle profileswhich comprise the total number of drivers and the behavior of each ofthose drivers. The RPU 160 may then generate updated pricing informationbased on the risk assessment (S1280). The website system 120 maycommunicate the updated pricing information to a user device 130(S1290). The website system 120 may further communicate suggestedchanges in driving behavior that may be used to receive a discount.

FIG. 13 shows another flow diagram for a method 1300 for expectationbased processing. This application incorporates the entire contents ofU.S. patent application Ser. No. 14/145,165, filed Dec. 31, 2013 byreference as if fully set forth. In the method 1300 shown in FIG. 13 ,the system 100 determines a driver proxy score for each driverassociated with a vehicle 140 at S1310. The driver proxy score may bebased on demographic information provided by the driver or it may bebased on previous data regarding the driver (for example, from recordeddata the previous year). The system 100 may then receive telematics datafrom a telematics collection server (S1320). For example, the telematicscollection server may receive sensed data from the smartphone 110. Thistelematics collection server may be operated by a third-party vendor orby the insurance company or any suitable party. This information may beformatted and electronically transmitted to the DPU 170. The DPU 170 mayuse a software based algorithm to determine a driver telematics scorefor each driver (S1330). The DPU 170 may then determine an expectationbased rating for each driver (S1340). The RPU 160 may be configured touse a multivariate analysis to generate updated pricing information(S1350). This information may be determined on an individual telematicsfactor basis. The system 100 may format this information and thendisplay it to the display of a user device 130 (S1360). The display mayindicate specific factors on which a credit or penalty was assessed andan overall presentation of driving behavior. The display may furtherprovide the user with a graph showing the driver's behavior versus theexpectation as well as the hypothetical baseline driver. The system 100may further be configured to provide the display with informationregarding suggested changes to driving behavior which may save thedriver money.

The system 100 may provide this information at a predetermined renewalperiod or based on a triggering event. A triggering event may occur, forexample based on the variance of the telematics data to an expectedvalue or any event or observed data that may adjust expected losses.

FIG. 14 shows a flow diagram for a method 1400 for destination basedunderwriting. This application incorporates the entire contents of U.S.patent application Ser. No. 14/145,181, filed Dec. 31, 2013 by referenceas if fully set forth. Based on the received biographical information,the DPU 170 may determine a proxy destination score for each vehicle(S1410). In one example, the proxy destination score may be based on thehome/garaging ZIP code. As another example, the proxy destination scoremay be based on previously measured data associated with the vehicle 140or vehicle owner. A telematics collection server may receive telematicsdata from a smartphone associated with the vehicle 140 (S1420). Thetelematics collection server may format and forward the telematics datato the DPU 170 (S1430). The DPU 170 may then analyze the receivedtelematics data and categorize locations indicated in the telematicsdata as destinations (S1440). Wherein a destination may be determinedbased on a minimum duration at a location. Based on the evaluationperiod (e.g. one month, 2 months, year, or time between renewals), theDPU 170 determines the relative percentage of time the vehicle 140spends at each destination (S1450). The DPU 170 determines a destinationrelativity factor based on the percentage of time the vehicle spends ateach location, the rating of each location, the home/garaging ZIP, andthe rating of the home/garaging zip (S1460). The RPU 160 generatesupdated pricing information based on the destination relativity factor(S1470). The website 120 may provide the updated pricing information toa user device 130 (S1480). The updated pricing information may includean adjusted rate, or debits or credits determined by the RPU 160. Theweb site system 120 may also provide the user device 130 with additionalinformation, such as recommendations on where to store the vehicle toreceive a discount.

FIG. 15 shows an example graph 1500 for a DLRI for a ZIP code basedcalculation. This application incorporates the entire contents of U.S.patent application Ser. No. 14/145,205, filed Dec. 31, 2013 by referenceas if fully set forth. As shown in FIG. 15 , a map is comprised withcircles of different color/size to indicate the categorization for anarea based on ZIP code. The DLRI may be determined by the DPU 170 basedon loss data received by the DPU 170. This loss data may be directlymeasured by the DPU 170, or it may be received from an external server180. The DPU 170 may determine multiple DLRI maps for each type ofcoverage. The DPU 170 receives telematics data regarding the location ofthe vehicle 140. The DPU 170 determines the amount of time spent in eachrisk category. A driving location relativity factor is determined basedon this information. The RPU 160 may use this driving locationrelativity factor in determining an adjustment to the pricinginformation. While the example shown in FIG. 15 shows only a limitednumber categories are assigned for each ZIP code, the system 100 may usemore or less categories. Additionally, while the example shown in FIG.15 shows the unit area of the DLRI calculation as the area representedby a ZIP code, the actual unit of area may be different.

As described above, the relativity factors may be based on differentunits of area. In another example, the relativity factors may bedetermined relative to road segments travelled (e.g. braking per roadsegment).

FIG. 16 is a block diagram of a system 1600 for determining a discountfor an insurance premium based on telematics data according to anillustrative embodiment. The system 1600 uses data collected alongmultiple trips traveled by a vehicle, including, for example, speedinginformation, time of day information, and/or safety event information.An insurance company may use route data, such as Global PositioningSatellite (“GPS”) latitude and longitude data, acceleration/decelerationdata, speed data, and/or vehicle orientation data collected along aroute traveled by the vehicle to determine an insurance premium discountto be associated with a driver and/or a vehicle. With a sufficientamount of data, the insurance company can calculate a level of riskscore for the driver based on, for example, the driver's driving habits.The insurance company can use the score for setting or adjusting adiscount value to be applied to an insurance premium. In someimplementations, a score or discount is determined by a third-party dataprocessing service. In addition, the score or discount may be set by anunderwriter, which may be a part of the insurance company or otherwiseaffiliated with or in a third-party arrangement with the insurancecompany. According to any embodiments described here, a score might beused to determine a premium price, a premium adjustment, and/or anyother benefit that may be associated with an insurance policy (e.g., adecreased deductible value or increased overall coverage amount).

The system 1600 includes one or more vehicles 1602, each having asmartphone 1604. The vehicle 1602 may be an automobile, motorcycle,truck, bus, watercraft, aircraft, or any other vehicle operated by adriver. A smartphone 1604 is coupled to a vehicle 1602 for collectingdata about the vehicle's location, movements, or other information thatcan be used to determine risk scores. For vehicles with multipledrivers, the data may be associated with the vehicle itself or with theindividual drivers. The smartphone 1604 may be positioned inside thevehicle 1602 or be directly coupled to the vehicle 1602. The smartphone1604 is in communication with an insurance company system 1608 over acommunication network 1650. The smartphone 1604 may communicate with theinsurance company system 1608 though a wireless network such as acellular network or using a wireless Internet connection. In general,the smartphone 1604 can be any computing device or plurality ofcomputing devices in cooperation having a data collection sensor (e.g.,an antenna or an accelerometer), a processor, a memory, and a means fortransmitting the collected data. The customer vehicle 1602 or smartphone1604 may include an antenna for receiving signals from Global NavigationSatellite System (“GNSS”) satellites, numbered 16 through “n” in FIG. 16. In one implementation, the smartphone 1604 is also configured toprocess the collected data. In some embodiments, the data processingprotects the driver's privacy by encrypting the data, removing locationinformation, producing summary information, or taking other measures toreduce the likelihood that location information, speed information, orother sensitive information are received by the insurance company orthird parties.

In some embodiments, rather than sending collected data directly to theinsurance company system 1608, the smartphone 1604 sends collected datato a data processing service 1606, which processes the data to determinea risk score and/or an appropriate premium discount for a driver that isthen sent to the insurance company system 1608. This can help protect adriver's privacy, since the insurance company does not get detailed dataabout a driver's location, but only receives summary information. Usinga data processing service 1606 is in some implementations alsopreferable to having the smartphone 1604 process data to output a riskscore because it reduces the processing power needed by smartphone 1604and because using a third-party data processing service 1606 may alsomake it more difficult for drivers to tamper with the data. The dataprocessing service 1606 can perform additional monitoring functions,such as vehicle security monitoring or providing location-based alerts(e.g., alerting a parent or employer when a vehicle travels an unusualpath) and/or speed alerts. Note that an insurance company might receivedetailed reports from the third-party data processing service 1606,summary reports (with certain details removed), and/or supplementedinformation (e.g., including information from one or more publicdatabases).

The insurance company system 1608 includes a plurality of applicationservers 1612, a plurality of load balancing proxy servers 1614, aninsurance company database 1616, a processing unit 1620, and companyterminal 1622. These computing devices are connected by a local areanetwork 1624.

The application servers 1612 are responsible for interacting with thesmartphone 1604 and/or the data processing service 1606. The dataexchange between the insurance company system 1608 and smartphone 1604and/or data processing service 1606 can utilize push and pulltechnologies where the application servers 1612 of the insurance companysystem 1608 can act as both a server and client for pushing data to thedata processing service 1606 (e.g., which vehicles to monitor, when tostop data collection, rules for monitoring services requested by thecustomer) and for pulling data from the data processing service 1606.The application servers 1612 or other servers of the insurance companysystem 1608 can request to receive periodic data feeds from thesmartphone 1604 and/or data processing service 1606. The communicationbetween the application servers 1612 and the data processing service1606 can follow various known communication protocols, such as TCP/IP.Alternatively, the application servers 1612 and data processing service1606 can communicate with each other wirelessly, e.g., via cellularcommunication, Wi-Fi, Wi-Max, or other wireless communicationstechnologies or combination of wired or wireless channels. The loadbalancing proxy servers 1614 operate to distribute the load amongapplication servers 1612.

The insurance company database 1616 stores information about vehicularinsurance policies. For each insurance policy, the database 1616includes for example and without limitation, the following data fields:policy coverage, a risk rating, policy limits, deductibles, the agentresponsible for the sale or renewal, the date of purchase, dates ofsubsequent renewals, product and price of product sold, applicableautomation services (for example, electronic billing, automaticelectronic funds transfers, centralized customer service planselections, etc.), customer information, customer payment history,smartphone 1604 information, or derivations thereof. Note that any ofthe embodiments described herein might be associated with existinginsurance policies, newly issued insurance policies, and/or policiesthat have not yet been issued (e.g., during a trial phase before apolicy is issued). According to some embodiments, information collectedduring a trial period may influence a discount or other benefit that iseventually associated with an insurance policy.

The processing unit 1620 is configured for determining the price of aninsurance premium based on a risk rating for a driver or vehicle. Theprocessing unit 1620 may comprise multiple separate processors, such asa risk or safety processor, which may calculate a safety rating from rawor processed data from the smartphone 1604 or data processing service1606 over the communications network 1650; and a business logicprocessor, which determines a premium price for a policyholder based on,among other things, a risk score. In some embodiments, insurance premiumprices or information for making insurance pricing determinations may begenerated by a third-party underwriter, which is separate from theinsurance company system 1608.

The company terminals 1622 provide various user interfaces to insurancecompany employees to interact with the processing system 1620. Theinterfaces include, without limitation, interfaces to review telematicsdata, or risk ratings; to retrieve data related to insurance policies;to manually adjust a risk rating; and to manually adjust premiumpricing. In some instances, different users may be given differentaccess privileges. For example, marketing employees may only be able toretrieve information on insurance policies but not make any changes todata. Such interfaces may be integrated into one or more websites formanaging the insurance company system 1608 presented by the applicationservers 1612, or they may be integrated into thin or thick softwareclients or standalone software. The company terminals 1622 can be anycomputing devices suitable for carrying out the processes describedabove, including personal computers, laptop computers, tablet computers,smartphones, servers, and other computing devices.

The user terminal 1630 provides various user interfaces to customers tointeract with the insurance company system 1608 over the communicationsnetwork 1650. Potential customers can use user terminals 1630 toretrieve policy and pricing information for insurance policies offeredby the insurance company. Customers can enter information pertaining tochanges in their insurance policy, e.g., changes in policy coverage,addition or subtraction of drivers, addition or subtraction of vehicles,relocation, mileage information, etc. Customers can also use the userterminal 1630 for a pay-as-you-go insurance policy in which customerspurchase insurance by the trip or mile.

In some embodiments, the smartphone 1604 may not be continuallyconnected to the insurance company system 1608 via the network 1650. Forexample, the smartphone 1604 may be configured to temporarily store dataif the smartphone 1604 becomes disconnected from the network, like whenit travels out of range of cellular towers. When the connection isrestored, the smartphone 1604 can then transmit the temporarily storeddata to the insurance company system 1608. The smartphone 1604 mayalternatively be configured to connect to the communications network1650 through a user's home Wi-Fi network. In this case, the smartphone1604 stores trip data until it returns to the vicinity of the user'shome, connects to the user's wireless network, and sends the data. Insome embodiments, the smartphone 1604 is not connected to the network1650 at all, but rather, data collected is transmitted to the insurancecompany through other means. For example, a customer can receive asmartphone 1604 from the insurance company, couple the device 1604 tohis car for a set period of time or number of miles, and then eithermail the device 1604 with the collected data to the insurance companysystem 1608 or extract and send the collected data to the insurancecompany system 1608 via mail, email, or through a website.

The vehicle 1602 and smartphone 1604 may be associated with, forexample, an automobile. For example, FIG. 17 illustrates an automobile1700 in accordance with some embodiment of the invention. The automobile1700 may be associated with a smartphone used to collect telematicsinformation. Note that telematics information might instead beassociated with, for example, a motorcycle, a recreational vehicle, aboat, an airplane, etc. According to some embodiments, the automobile(or other machine) is associated with a primary axis of movement(illustrated by a solid arrow in FIG. 17 ) and a prediction of whetheror not a smartphone is associated with a driver or passenger is based atleast in part on movement of the mobile personal communication devicerelative to the primary axis of movement prior to operation of themachine. For example, as illustrated by the dashed arrow in FIG. 17 , itmight be determined if the smartphone (and presumably the personcarrying the smartphone) entered the vehicle via the driver's side cardoor or the passenger's side car door (e.g., based on the direction ofmovement of the smartphone immediately before driving began). Accordingto another embodiment, automobile 1700 or machine is associated with aprimary direction of movement and the prediction is based at least inpart on a location of the mobile personal communication device relativeto the primary direction of movement during operation of the machine.

FIG. 18 is a flowchart of a method 1800 for determining an insurancepolicy benefit for a driver or vehicle based on telematics data. Themethod 1800 can be performed by the smartphone 1604, the data processingservice 1606, the insurance company system 1608, or any combination ofthese. The method 1800 includes the step of collecting preliminarytelematics data via a smartphone associated with a driver of a vehicle(S1810). For example, a smartphone application might determine and/orcollect time of day information associated with driving, day of week,location, velocity, and/or mileage information.

An initial benefit is calculated based on the preliminary telematicsdata and a policy is issued in accordance with that benefit in exchangefor receiving data indicative of actual telematics data (S1820). Forexample, an insurance company may offer a driver a 5% initial discountto his or her insurance premium if he or she agrees to participate in atelematics program. Another driver, associated with preliminarytelematics data (collected by a smartphone) indicating a potentiallyhigher level or risk might only be offered a 3% initial premiumdiscount. Other examples of policy benefits include a monetary discount(e.g., 100 dollars), an insurance coverage amount, and/or a deductibleamount. If the driver agrees, the insurance company may provide thedriver with an application to be installed in his or her smartphone. Thecalculated initial benefit may, according to some embodiments, encouragedrivers to participate in the telematics program. The method 1800 mayfurther include the storage of actual telematics data received from thesmartphone. To supplement the telematics data, embodiments might utilizedata from receivers and sensors such as a GNSS receiver, anaccelerometer, a vehicle computer, and/or vehicle telematics sensors.

It may then be determined that the data indicative of the actualtelematics data meets a pre-determined condition (S1830). For example,an insurance company might determine that actual telematics data hasbeen collected from a driver for three consecutive months or 2,000miles. After the pre-determined condition has been met, a final benefitfor the insurance policy may be computed based on the telematics data;and the initial discount may be replaced with the final discount(S1840). For example, based on actual telematics data it may bedetermined that the driver should actually receive a 16% discount. Inthis case, the initial 5% discount would be replaced by the 16% discountfor the insurance policy. According to some embodiments, an indicationof the final benefit for the insurance policy may be output (e.g., shownon a display or included in an email message to the driver).

According to some embodiments, prior to computing the final benefit, arange of potential benefits may be computed based on at least a portionof the actual telematics data. For example, consider a program where afinal discount is not calculated until three months of telematics datahas been collected. In this case, after two months of telematics datahas been collected, a likely range of potential insurance discountsmight be predicted and output to the driver. For example, a driver mightbe told that based on his or her driving habits during those two months,a discount of between 8% and 12% should be expected.

The telematics data used to compute a final discount or other insurancepolicy benefit might include, for example, times of day associated withdriving, velocities associated with driving, distances associated withdriving, weather information, and/or traffic information. Moreover, theinsurance company might identify safety events within the telematicsdata (e.g., hard brake events) and/or a severity estimation of thesafety events. Moreover, according to some embodiments an insuranceplatform might output an indication of a suggested driving modificationalong with a discount or other benefit goal for the insurance premium ofthe automobile insurance policy. For example, the driving modificationmight include a suggested route to a destination to achieve a 15%discount for an insurance premium.

Note that driving habits and conditions may change over time. Thus,according to some embodiments a driver may interact with a map displayto view safety events associated with a selected range of dates and/ortimes. For example, referring now to FIG. 19 , a diagram 1950 depictinganother user interface 1902 is shown. The user interface 1902 may bedisplayed on device 1900 such as a mobile telephone and may depict aportion of a map. The user interface 1902 may display to a driver thelocation of safety events 1954, 1956 (e.g., locations of rapidde-acceleration) that occurred during a particular period of time (e.g.,during the prior 24 hours, the prior week, the prior month, the prioryear, etc.). Note that the safety events 1954, 1956 might be associatedwith the driver's own driving habits or may reflect those of all driverswho have provided telematics data. According to some embodiments, adriver may interact with a “sliding scale” bar to select which period oftime should be used to filter the safety events 1954, 1956. Note thatthe identified safety events 1954, 1956 may associated with a pluralityof different event types. For example, safety events 1954, 1956 might beassociated with both hard braking events and excessive speeding. In thiscase, different labels (e.g., reflecting event types “1,” “2,” or “3” asillustrated in FIG. 19 ), icons, or colors may be used to differentiateevent types. Similarly, the safety events 1954, 1956 may be associatedwith different levels of risk or severity (e.g., high, medium, and lowintensity events) and these may also be differentiated on the userinterface 1902.

In some cases, a driver might be interested in a particular type ofsafety event. According to some embodiments, a selection of a particularevent type may be received from the driver and only indications of thesafety events associated with that particular event type may bedisplayed to the driver on the map display (e.g., only hard brakeevents). For example, referring now to FIG. 20 , a diagram 2050depicting another user interface 2002 is shown. As before, the userinterface 2002 may be displayed on device 2000 such as a mobiletelephone and may depict a portion of a map. The user interface 2002 maydisplay to a driver the location of safety events 2054, 2056 (e.g.,locations of rapid de-acceleration) that are of particular interest tothe driver. In the example of FIG. 20 , the driver has selected to viewall high intensity brake events. Note that the safety events 2054, 2056might be associated with the driver's own driving habits or may reflectthose of all drivers who have provided telematics data. Moreover,selection of a particular event icon might result in the display offurther details about that particular event (e.g., the date and time theevent occurred). In addition to, or instead of, filtering safety eventsbased on event type or severity, a driver might be able to displayevents associated with a particular type of driver or vehicle (e.g.,based on age, driving experience, gender, etc.).

In addition to the locations where safety events occurred, a drivermight be interested in his or her overall performance in connection withone or more types of safety events and/or how that performance comparesto others, how that performance is modifying his or her currentinsurance premium discount, etc. FIG. 21 illustrates a currenttelematics display 2100 according to some embodiments. In particular,the display 2100 includes a graphical representation 2110 of informationabout a particular risk variable derived from smartphone telematics datawhich may be categorized as “below average,” “average,” or “aboveaverage” from a risk perspective. The display 2100 also includes acurrent score (e.g., calculated at least in part based on the riskvariable) and a current discount (e.g., determined based on the currentscore). Note that the graphical representation 2110 might instead be asliding scale, letter grade (“B+”), or any other type of indication. Inaddition to, or instead of, a current number of events per week, adriver might be shown an average number of events for all drivers or fora particular type of driver or vehicle (e.g., based on age, drivingexperience, gender, etc.).

FIG. 22 illustrates another current telematics display 2200 according tosome embodiments. In particular, the display 2200 includes a graphicalrepresentation 2210 of information about three different risk variablesderived from telematics data, a current score (e.g., calculated based onthe risk variables) and a current discount or other policy benefit(e.g., determined based on the current score). The current discountmight, according to some embodiments, represent the final discount.According to some embodiments, the current discount might be calculatedin substantially real time or be recalculated using new data when thedriver's safety scores are more likely change, e.g., if the customermoves, changes jobs, has a child, or retires, or at certain timeperiods, e.g., every year, every two years, every three years, everyfive years, every ten years, etc. In some embodiments, both prospectivepricing and retroactive pricing are used. For example, a customer beingcontinually monitored might receive a premium discount for a time periodbased on one or more past safety scores, and if the customer's actualscore rating for the time period was greater than or less than theexpected rating, an adjustment may be applied as appropriate.

By way of example only, a score model might consist of two mainelements: (1) a percentage of time speeding over a threshold value(e.g., 75 miles per hour) and (2) an annualized miles value associatedwith times of day. Each driver's score might, for example, start withfifteen (15) points then be modified by adding speeding points and/orsubtracting time of day mileage by the factors shown below:

For Time of Day:

Risk Level Per Mile Subtraction Risky 0.005 Moderate 0.0025 Low 0.00125Where “risky” is defined as driving between midnight and 4:00 am everyday of the week, “moderate” is driving from 4:00 am to 6:00 am and 9:00pm to midnight every day of the week and 6:00 am to 9:00 am and 3:00 μmto 6:00 pm on weekdays. “Low” risk times may comprise all other times ofthe day.

For Speeding over a Threshold:

% Time Speeding Points >0.75% 0 0.1-0.75% 5 <0.1% 10

In such an example, consider a driver who drives 5,000 annualized miles.Moreover, 4,000 of these miles are driven during moderate risk times ofthe day and 1,000 of these miles are driven during low risk times of theday. Moreover, the driver speeds over the threshold 0.05% of the time.In this case, a safety score might be determined as follows: SafetyScore=15+10−(4,000*0.0025+1,000*0.00125)=13.75. Rounding this to thenearest whole number and looking it up in a risk/discount table, thedriver might receive a 14% discount for his or her insurance premium.

As another example, aggressive driving/hard braking events might beclassified into different intensity or severity levels. For example, atype 1 event might have a threshold of from 340 to 500 milli-g (˜ changein speed or velocity (Δ) of greater than +/−7.5 mph/sec²) (e.g., from 14mph to 25 mph in 1 second). A type 2 event might have a threshold offrom 501 to 750 milli-g (˜ change in speed or velocity (Δ) of greaterthan +/−11 mph/sec²) (e.g., from 65 mph to 45 mph in 1 second). A type 3event might have a threshold of 750 milli-g (˜ change in speed orvelocity (Δ) of greater than +/−16.5 mph/sec²) (e.g., from 65 mph to 35mph in 1 second). The severity of the event may then be used whendetermining an insurance premium discount of the driver.

Note that a driver's safety score will change over time based on his orher driving habits. FIG. 23 is an example of a safety score display 2300that might be provided to a driver according to some embodiments. Inparticular, the display 2300 includes a graph 2310 showing the driverssafety score over a particular period of time (e.g., over the last monthor year). According to some embodiments, a driver may select the periodof time depicted on the graph 2310. Such a safety score display 2300 mayencourage a driver to improve his or her safety score and become a lessrisky driver.

An insurance premium discount or other benefit may be based at least inpart on telematics data, a driver's safety score, and/or safety eventsthat occur over time. According to some embodiments, a final discountvalue may not be determined until telematics data has been collected fora predetermined period of time and/or a predetermined number of miles.Even before the final discount value is determined, a likely discountvalue might be calculated based on a driver's known driving habits. Forexample, during a trial or initial period, a likely discount value mightbe calculated based on safety events that have occurred during the trialperiod. FIG. 24 illustrates a likely discount display 2400 according tosome embodiments. In particular, the display 2400 includes a currentmost likely discount 2410 calculated based on the existing telematicsdata that has been collected for that driver. Moreover, an upper likelydiscount 2420 and lower likely discount 2430 may also be displayed(e.g., there might be a 90% chance that the driver's final discount willnot exceed the upper likely discount 2420). Note that as more telematicsdata is collected over time, the upper and lower likely discounts 2420,2430 might converge until, at the end of a trial period, the finalpremium discount is actually computed for the driver.

According to some embodiments, an initial insurance policy benefit mightbe calculated based on preliminary telematics data collected by asmartphone and be provided to a driver while actual telematics data iscollected. FIG. 25 is an illustration 2500 of how an insurance premiummight change over time according to some embodiments. A baselineinsurance premium associated with what a driver would pay if he or shedid not participate in a telematics program is represented by a dashedline 2510 in FIG. 25 along with a solid line 2520 representing his orher actual premiums that begin on the date the insurance policy isissued (represented by a dotted line in FIG. 25 ). During a period 2530prior to issuance of the insurance policy, preliminary telematics datais collected by a driver's smartphone. After the policy is issued andthe driver agrees to participate in the program, actual telematics datais collected 2540 (e.g., by a smartphone application provided by theinsurance company) until a pre-determined condition is met (e.g., threemonths of actual telematics data has been collected). During this time2540, the driver's insurance premium is reduced by an initial discountamount that is calculated based at least in part on the preliminarytelematics data collected by the driver's smartphone during time 2530.After the pre-determined condition is met, a final discount amount isdetermined and applied to his or her insurance premium (and the finalamount might be more or less than the initial discount depending on hisor her driving habits as reflected by the actual telematics data).

It may be difficult for a driver to predict or understand exactly howhis or her driving habits will adjust a safety score or premium discountvalue. According to some embodiments, a telematics calculator may beprovided for a driver to reduce this problem. For example, FIG. 26 is atelematics calculator 2600 where a driver can predict safety events ofvarious severity or intensity levels. In the example of FIG. 26 , adriver predicts how many “high,” “medium,” and “low” intensity hardbrake events will occur each week. According to other embodiments, agraphical representation 2610 may be used to reflect the enteredinformation and/or may be used instead by the driver to enterinformation (e.g., by rotating a gauge or dial). Based on thisinformation, the calculator 2600 may generate and display a predictedscore and/or discount value.

According to other embodiments, a driver might enter a desired score orpremium discount value. For example, FIG. 27 is an example of aninsurance discount calculator 2700 in accordance with some embodimentsdescribed herein. The calculator 2700 may receive from a driver adesired premium discount via a sliding scale 2710 movable via computermouse pointer 2750 (e.g., in the example of FIG. 27 the driver isinterested in receiving a 10% discount). Based on the desired discount,the calculator 2700 generates a number of safety events for varioustypes of events and/or various levels of severity. For example, thecalculator 2700 might indicate that 5 high intensity hard brake eventsshould be experienced per week in order for the driver to receive a 10%discount. The calculator 2700 may be, for example, associated with a webpage, a smartphone application, and/or a kiosk and may encourage driversto adopt less risky driving habits.

The embodiments described herein may be implemented using any number ofdifferent hardware configurations. For example, FIG. 28 illustrates anapparatus 2800 that may be, for example, associated with system thatutilizes telematics data collected via a smartphone associated with amachine. The apparatus 2800 comprises a processor 2810, such as one ormore commercially available Central Processing Units (“CPUs”) in theform of one-chip microprocessors, coupled to a communication device 2820configured to communicate via a communication network (not shown in FIG.28 ). The communication device 2820 may be used to communicate, forexample, with one or more remote administrator computers and orcommunication devices (e.g., PCs and smartphones). Note thatcommunications exchanged via the communication device 2820 may utilizesecurity features, such as those between a public internet user and aninternal network of the insurance enterprise. The security featuresmight be associated with, for example, web servers, firewalls, and/orPCI infrastructure. The apparatus 2800 further includes an input device2840 (e.g., a mouse and/or keyboard to enter information aboutpre-determined driver prediction rules to automatically and dynamicallyadjust a data input flow, etc.) and an output device 2850 (e.g., tooutput reports regarding insurance premium discounts).

The processor 2810 also communicates with a storage device 2830. Thestorage device 2830 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g., a harddisk drive), optical storage devices, mobile telephones, and/orsemiconductor memory devices. The storage device 2830 stores a program2815 and/or a smartphone telematics tool or application for controllingthe processor 2810. The processor 2810 performs instructions of theprogram 2815, and thereby operates in accordance with any of theembodiments described herein. For example, the processor 2810 maymonitor operation of a machine and provide feedback to maintain usewithin certain parameters. Mobile personal communication device sensorsmay each be configured to monitor at least one machine parameter (speed,acceleration, location, etc.), generate a signal encapsulating themonitored machine parameter, and transmit the generated sensor signalsto a control unit of the communication device. The control unit mayreceive the generated sensor signals, store the received signals, andselectively combine the received signals. The communication device alsoincludes a transmitter coupled to the control unit capable oftransmitting the combined signal. The processor 2810 may then determinea current machine condition and compare that condition to receivedconditions from other machines. Feedback may then be provided to adjustoperation of the machine based on the comparison. For example, anoperator interface may provide audio and/or visual feedback to theoperator of a vehicle.

The program 2815 may be stored in a compressed, uncompiled and/orencrypted format. The program 2815 may furthermore include other programelements, such as an operating system, a database management system,and/or device drivers used by the processor 2810 to interface withperipheral devices.

As used herein, information may be “received” by or “transmitted” to,for example: (i) the back-end application computer server 2800 fromanother device; or (ii) a software application or module within theback-end application computer server 2800 from another softwareapplication, module, or any other source.

In some embodiments (such as shown in FIG. 28 ), the storage device 2830further stores a smartphone database 2900, a vehicle database 3000, adriver database 3100, and a risk relationship database 2860 (e.g.,storing information about insurance policies). Examples of databasesthat might be used in connection with the apparatus 2800 will now bedescribed in detail with respect to FIGS. 29 through 31 . Note that thedatabases described herein are only examples, and additional and/ordifferent information may be stored therein. Moreover, various databasesmight be split or combined in accordance with any of the embodimentsdescribed herein. For example, the vehicle data database 3000 and driverdatabase 3100 might be combined and/or linked to each other within theprogram 2815.

Referring to FIG. 29 , a table is shown that represents the smartphonedatabase 2900 that may be stored at the apparatus 2900 according to someembodiments. The table may include, for example, entries associated withsmartphones that collect telematics data. The table may also definefields 2902, 2904, 2906, 2908, 2910 for each of the entries. The fields2902, 2904, 2906, 2908, 2910 may, according to some embodiments,specify: a vehicle identifier 2902, a customer name and policy number2904, a date and time 2906, a smartphone identifier 2908, and a vehiclespeed 2910. The smartphone database 2900 may be created and updated, forexample, based on information electrically received from variouscomputer systems, including those associated with insurance provider.

The vehicle identifier 2902 may be, for example, a unique alphanumericcode identifying a vehicle (e.g., an automobile to be insured). Thecustomer name and policy number 2904 may identify, for example, an ownerof the vehicle and insurance policy number. The date and time 2906 mightindicate when the entry was updated and the smartphone identifier 2908might indicate the mobile personal communication device that sensed andprovided telematics data. For example, the vehicle speed 2910 mightindicate telematics data sensed and reported by a smartphone inconnection with operation of an insured vehicle (or a vehiclepotentially to be insured).

Referring to FIG. 30 , a table is shown that represents the vehicledatabase 3000 that may be stored at the apparatus 3000 according to someembodiments. The table may include, for example, entries associated withsmartphones that collect telematics data. The table may also definefields 3002, 3004, 3006, 3008, 3010 for each of the entries. The fields3002, 3004, 3006, 3008, 3010 may, according to some embodiments,specify: a vehicle identifier 3002, a customer name and policy number3004, a manufacturer and model 3006, safety feature 1 3008, and safetyfeature N 3010. The vehicle database 3000 may be created and updated,for example, based on information electrically received from variouscomputer systems, including those associated with insurance provider.

The vehicle identifier 3002 may be, for example, a unique alphanumericcode identifying a vehicle (e.g., an automobile to be insured) and maybe based on or associated with the vehicle identifier 2902 in thesmartphone database 2900. The customer name and policy number 3004 mayindicate an owner or driver of the vehicle and the manufacturer andmodel 3006 may describe the vehicle. The vehicle database 3000 may storeinformation about safety features of the vehicle including, for example,safety feature 1 3008 through safety feature N 3010 (e.g., anti-lockbrakes, adaptive headlights, tire pressure sensors, etc.).

Referring to FIG. 31 , a table is shown that represents the driverdatabase 3100 that may be stored at the apparatus 3100 according to someembodiments. The table may include, for example, entries associated withsmartphones that collect telematics data. The table may also definefields 3102, 3104, 3106, 3108, 3110 for each of the entries. The fields3102, 3104, 3106, 3108, 3110 may, according to some embodiments,specify: a driver identifier 3102, a machine learning algorithm 3104,distracted driving 3106, a smartphone identifier 3108, and a driverrating 3110. The driver database 3100 may be created and updated, forexample, based on information electrically received from variouscomputer systems, including those associated with insurance provider.

The driver identifier 3102 may be, for example, a unique alphanumericcode identifying a person predicted to be operating a vehicle, and themachine learning algorithm 3104 might identify how that prediction wasmade. The distracted driving 3106 might indicate, for example, that thedriver was texting, participating in a telephone call, etc. Thesmartphone identifier 3108 might indicate a personal mobilecommunication device that is reporting telematics data, and the driverrating 3110 might indicate a level of risk associated with the operatorof the vehicle (based on telematics data received from the smartphone).

FIG. 32 is a real-time information flow diagram of a processing system3200 in accordance with some embodiments. In particular, an event bus3250 may utilize a publisher-subscriber model to exchange event signalsthat an event has occurred (e.g., as opposed to a command to makesomething happen). The use of such an event bus 3250 may efficiently leta substantial number of entities realize that an event occurred and mayconform to a common canonical model. For example, customer relationshipmanagement and database 3220, enterprise subscription/publishingadaptors 3260, telematics vendor enrollment 3270, and telematicsanalytics services 3280 (e.g., that analyzes the aggregated telematics,policy, customer experience and third party data, collectively known asbig data, to determine compliance with telematics program, risk scoringand digital experience actions and insights) may interface with theevent bus 3250 and provide data to third parties (and the ability toreceive data from third parties), a telematics mobile application, etc.Product sales and service portals 3220 may create and utilize insurancepolicy and/or premium data. According to some embodiments, a productsales and service portal 3220 may query driver and vehicle eligibilityrules 3230 (e.g., to determine if a driver and/or vehicle qualifies toparticipate in a telematics program). The driver and vehicle eligibilityrules 3230 may be defined using historical information derived fromtelematics analytics services 3280 to improve risk selection. This typeof processing system 3200 architecture may allow for plug-and-playdesign as well as device and/or vendor agnostic interfaces to leveragean IT infrastructure for insurance purposes.

Thus, embodiments may provide an automated and efficient way forremotely monitoring and/or controlling the use of a machine thatprovides faster, more accurate results.

The following illustrates various additional embodiments of theinvention. These do not constitute a definition of all possibleembodiments, and those skilled in the art will understand that thepresent invention is applicable to many other embodiments. Further,although the following embodiments are briefly described for clarity,those skilled in the art will understand how to make any changes, ifnecessary, to the above-described apparatus and methods to accommodatethese and other embodiments and applications.

Although specific hardware and data configurations have been describedherein, note that any number of other configurations may be provided inaccordance with embodiments of the present invention (e.g., some of theinformation associated with the displays described herein might beimplemented as a virtual or augmented reality display and/or thedatabases described herein may be combined or stored in externalsystems). Moreover, although embodiments have been described withrespect to particular types of insurance policies, embodiments mayinstead be associated with other types of insurance policies inadditional to and/or instead of the policies described herein (e.g.,business insurance policies, motorcycle insurance policies, etc.).Similarly, although certain attributes were described in connection someembodiments herein, other types of attributes might be used instead.

According to some embodiments a risk score and/or driver signature datamight be made available to another insurance company in connection witha future automobile insurance policy associated with the driver. Forexample, a driver's risk score might travel with him or her when theyswitch insurance companies (e.g., like a credit score might follow aperson). A risk score might, in some embodiments, be associated withlead generation (e.g., to target better drivers with insurance offers)and/or gamified digital engagement to improve driving performance.

According to some embodiments, a risk score may be used to facilitate anincremental insurance policy. For example, an incremental insurancepolicy might be a “pay-per-mile” policy for infrequent drivers based ona number of miles driven. Similarly, an incremental insurance policymight instead be based on an amount of time spent driving (e.g.,“pay-per-hour” insurance).

As described herein, information from a mobile personal communicationdevice may be used in connection with risk score determinations and/orinsurance underwriting decisions. Note, however, that information fromthe mobile personal communication device (e.g., a smartphone app) mightalso be used for other purposes. For example, a smartphone might offervehicle diagnostics (e.g., associated with a battery life alert and/orroad side assistance). As other example, the smartphone might beutilized for accident detection and/or adjudication, insurance claimprocessing (e.g., reducing the need for claim handler involvement), aFirst Notice Of Loss (“FNOL”) and associated time requirements, etc.

According to some embodiments, the prediction of the operator identifiermay be further based on social media data or other third-party data. Forexample, a social media post might indicate that a particular person isat an event (and this can be used to predict that he or she is thedriver on the way home from the event). In some embodiments, this typeof information might even be used to retroactively “correct” aprediction of an operator identifier.

As described herein, information from a mobile personal communicationdevice is used to predict operator identifiers and/or to facilitate riskscore calculations. Note, however, that information from other devicesmight supplement these processes. For example, information from anapparatus coupled to the machine (e.g., a tag or dongle) might be usedto supplement smartphone data. Similarly, information from a device indirect communication with the machine (e.g., while attached to awindshield or dashboard) could be used to supplement smartphone data.

The present invention has been described in terms of several embodimentssolely for the purpose of illustration. Persons skilled in the art willrecognize from this description that the invention is not limited to theembodiments described, but may be practiced with modifications andalterations limited only by the spirit and scope of the appended claims.

What is claimed:
 1. A system configured to monitor use conditions of amachine and provide feedback to an operator of the machine to maintainuse within certain parameters, comprising: a mobile personalcommunication device associated with the operator and located proximateto the machine, including: a plurality of sensors, each sensorconfigured to monitor at least one parameter, the plurality of sensorsselected from acceleration, speed, mileage, run-time and locationsensors, each sensor generating a sensor signal encapsulating themonitored parameter and transmitting the generated sensor signal, acontrol unit including a control unit memory that receives and storesthe transmitted sensor signals and selectively combines the sensorsignals, and a control unit transmitter coupled to the control unit thattransmits the combined signal; a transceiver remote from the machinethat receives the transmitted combined signal, and stores the combinedsignal in a memory unit, and a processor that processes the combinedsignal to capture the signal from each of the plurality of sensors, andcompares a condition identified by the captured signals to receivedconditions from other mobile personal communication devices and providesan adjustment signal to the transceiver to broadcast to the mobilepersonal communication device providing feedback to adjust the use ofthe machine based on the comparison, wherein the comparison of thecondition utilizes a plurality of relativity factors, wherein each ofthe relativity factors is a numerical value generated based on thecomparison of the condition for the machine to the conditions for othermachines associated with corresponding conditions; and an operatorinterface for providing feedback to the operator of the machineincluding at least one indication associated with the adjustment signal.2. The system of claim 1, wherein the feedback is at least one of avisual indication and an audible indication provided via the mobilepersonal communication device.
 3. The system of claim 1 wherein thefeedback is provided to cause a physical alteration of operation of themachine.
 4. The system of claim 3 wherein the machine is a vehicle andphysically altering operation of the vehicle includes at least one of:(i) applying brakes, (ii) lowering a volume of a radio, and (iii)turning from a location.
 5. The system of claim 1, wherein the processorthat processes the combined signal also automatically predicts anoperator identifier associated with received machine information,wherein said prediction utilizes a prediction algorithm based on apattern detected via a machine learning analysis of past operator usageof the machine.
 6. The system of claim 5, wherein the predicted operatoridentifier and the combined signal are used to calculate a risk score.7. The system of claim 6, wherein a record for the operator of themachine is updated with the risk score.
 8. The system of claim 6,wherein the calculated risk score is also based on at least one machinesafety feature associated with a machine identifier.
 9. The system ofclaim 8, wherein the machine safety feature is at least one of adaptiveheadlights, an autonomous operation feature, a camera, a sensor, anautomatic braking feature, a brake warning feature, a parking featureand a lane departure warning.
 10. The system of claim 1 wherein at leastone of the plurality of relativity factors is based on a predeterminedroad segment.
 11. The system of claim 1 wherein at least one of theplurality of relativity factors is a braking relativity factor, aspeeding relativity factor, and a time of day relativity factor.
 12. Acomputerized method to monitor use conditions of a machine and providefeedback to an operator of the machine to maintain use within certainparameters, comprising: monitoring, by a plurality of sensors includedin a mobile personal communication device associated with the operator,a plurality of parameters, wherein each sensor is configured to monitorat least one parameter, the plurality of sensors selected fromacceleration, speed, mileage, run-time and location sensors, each sensorgenerating a sensor signal encapsulating the monitored parameter andtransmitting the generated sensor signal, receiving and storing, by acontrol unit of the mobile personal communication device, the controlunit including a control unit memory, transmitted sensor signals,selectively combining, by the control unit, the sensor signals,comparing a condition identified by the combined sensor signals toreceived conditions from other mobile personal communication device,providing an adjustment signal based on the comparison, wherein theadjustment signal provides feedback to adjust the use of the machine,and wherein the comparison of the condition utilizes a plurality ofrelativity factors, wherein each of the relativity factors is anumerical value generated based on the comparison of the condition forthe machine to the conditions for other machines associated withcorresponding condition.
 13. The method of claim 12, wherein thefeedback is at least one of a visual indication and an audibleindication provided via the mobile personal communication device. 14.The method of claim 12, wherein the feedback is provided to cause aphysical alteration of operation of the machine.
 15. The method of claim14 wherein the machine is a vehicle and physically altering operation ofthe vehicle includes at least one of: (i) applying brakes, (ii) loweringa volume of a radio, and (iii) turning from a location.
 16. The methodof claim 12, further comprising: receiving machine informationrepresenting operation of the machine; and automatically predicting anoperator identifier associated with the received machine information,wherein the prediction utilizes a prediction algorithm based on apattern detected via a machine learning analysis of past operator usageof the machine.
 17. The method of claim 16, wherein the predictedoperator identifier and the combined signal are used to calculate a riskscore.